Category Archive: prog

Backuping these folders can eat up hundreds of gigabytes on the backup storage, and can cause significant performance reduction (some of them can contains millions of files).

~/.gradle
~/.npm
~/.composer
~/.cocoapods
~/.android/avd
~/Library/Developer/Xcode/DerivedData
~/Library/Application\ Support/JetBrains/Toolbox/apps
~/Library/Application\ Support/Google/Chrome/Default/Application Cache
~/Library/Developer/Xcode/iOS\ DeviceSupport

By removing these folders from the backups and excluding them in the System Preferences, the backup process can be faster and will consume less storage space.

1.  A szökőkútkódok és alkalmazásuk a végpontok közötti megbízható adatkommunikációban

1.1. Áttekintő

Napjainkban egyre többen és többen fogyasztanak hétköznapjaik során valamilyen online tartalmat, akik kiszolgálása érdekében a világ több pontján elhelyezett szerverek (szerverközpontok) felelnek. Ilyen nagyobb tartalom szolgáltató például a Youtube, a Vimeo, vagy épp a Facebook is. Élő streameket, televízió adásokat, vagy videófelvételeket nézhetünk bárhol, bármikor. Az otthoni személyi és a hordozható számítógépek fejlődésével, ezzel járó nagyobb teljesítményével, a szolgáltatott anyagok egyre jobb  és jobb minőségűek lehetnek, melyek arányosan egyre nagyobb sávszélességet igényelnek a tökéletes felhasználói és fogyasztói élményhez. A fogyasztói piac átalakulásával pedig, egyre nagyobb arányban használnak ezen célokra különféle vezetékes/nélküli eszközöket.

Az internetes adatkommunikációt az 1990-es évek elejétől, a HTTP (Hypertext Transfer Protocol) végzi a TCP (Transmission Control Protocol) protokoll segítségével, melyek együtt egy szabványos közeget biztosítanak bármilyen adat megbízható, veszteségmentes és sorrendtartó átvitelére. A TCP szabványosítása már 1981-ben (melyet azóta bővítettek a nagysebességű átvitelekhez igazodóan), a http szabványosítása pedig a 90-es évek elején megtörtént. Ezek a szabványok még az akkori alapvetően vezetékes és néhány kilobájtnyi kommunikációhoz nyújtottak megoldást, mely a mai fentebb említett egyre különfélébb eszközök és közegek számára nem mindig a legoptimálisabb.

Here it is my newest Clover build. Since last time I made a research again in the spd.c file and in the DDR4 SPD specification, and I realised that we can identify the speed from the Minimum Cycle Time and what is a most important thing: we must paging to access to upper 256byte of the SPD data.

The Mac OS Mavericks runs great on this laptop, but to get the wlan work, the original wifi card must be replaced.
The UEFI firmware prevent to start with other card than the original, which thing already made a lot of headaches to hp users.
I patched the firmware, and with an also patched flasher, I been able to overwrite the ROM with the modified version.

You can download the modificated files from here => sp54846.zip

I patched the Clover EFI bootloader, to get recognize the DDR4 RAM module size correctly, from the SPD datas.

diff --git a/rEFIt_UEFI/Platform/spd.c b/rEFIt_UEFI/Platform/spd.c
index 04c66d8..a7d389d 100644
--- a/rEFIt_UEFI/Platform/spd.c
+++ b/rEFIt_UEFI/Platform/spd.c

@@ -585,9 +585,24 @@ VOID read_smb(EFI_PCI_IO_PROTOCOL *PciIo)

case SPD_MEMORY_TYPE_SDRAM_DDR4:

+ DBG("SPD[%d]: spdbuf[4]: @0x%x n", i, spdbuf[4]);
+ DBG("SPD[%d]: spdbuf[5]: @0x%x n", i, spdbuf[5]);
+ DBG("SPD[%d]: spdbuf[12]: @0x%x n", i, spdbuf[12]);
gRAM.SPD[i].Type = MemoryTypeDdr4;
- gRAM.SPD[i].ModuleSize = spdbuf[4] & 0x0f;
- gRAM.SPD[i].ModuleSize = (1 << gRAM.SPD[i].ModuleSize) * 256;
+ // size = ((u64)rows * cols * banks * ranks) * bit;
+ // (spdbuf[4] & 0x30) >> 4 : bank address bits
+ // (spdbuf[4] & 0xC0) >> 6 : bank group bits
+ // banks = (4 << addressbits) * (1 << bank group bits)
+ // ((spdbuf[12] & 0x38) >> 3) :ranks
+ // (((spdbuf[5] & 0x38) >> 3)+12) :rows
+ // ((spdbuf[5] & 0x7)+9) : cols
+ gRAM.SPD[i].ModuleSize = (
+ (((UINT64)1 << (12 + ((spdbuf[ 5] & 0x38) >> 3))) *
+ (1 << (9 + ( spdbuf[ 5] & 0x07))) *
+ (1 + ((spdbuf[12] & 0x38) >> 3)) *
+ (4 << ((spdbuf[ 4] & 0x30) >> 4)) *
+ (1 << ((spdbuf[ 4] & 0xC0) >> 6))) >> (20 - 3)
+ );

break;

I added the skylake processor family definitions to the CPUSensors.kext, so it doesn’t cause kernel panic on boot.
It seems to the sensors work fine too.

My changes available on my GitHub profile: https://github.com/majonez/HWSensors

Most, hogy kicsit elmerültem az android világában, úgy gondolom, itt az ideje, hogy az oldalam is megkapja a kisebb, mobil kijelzőkre optimalizált külsejét.
Még néhány simítás hátra van, de már most is nagyon jól használható. Szerencsére régebben egész jól megírtam a témát, így a főmenün kívül, csak kisebb változtatások voltak szükségesek.

I released the third version of my CyanogenMod KitKat for GT-S7562.

Changelog:

• Improved Bluetooth support
• Most kernel debug flags disabled
• Added some missing libraries
• Merged all CyanogenMod source changes
• Bugfixes

You can find the download links on the xda-developers.com
My sources available on my GitHub profile.

I released the second version of my CyanogenMod KitKat for GT-S7562 with initial Bluetooth support.

Changelog:

• 1. Backported Bluetooth driver and Management Interface from Linux Kernel v.3.13
• 2. Newest Bluez 5.28 Bluetooth stack
• 3. Few bugfixes to wireless driver
• 4. All RC1 updates included

You can find the download links on xda-developers.com .

I’m proudly present my first Android releated work. :)

In december 2014, I got a GT-S7562 and I was not satisfied with its original Samsung firmware, because it was slow and has a lot of bloatware.
So I decided to make a working release of Cyanogenmod 11.
The GT-S7560M has a similar hardware except the dual-SIM RIL, so the kylessopen firmware (thanks to jonypx09) was a good initial source.
I reverse engineered the stock Java Radio Interface Layer, and based on that informations, I restructured the kylessopen’s sources.
Finally with my custom telephony-common, telephony-msim java layer, and with the stock rild, and libril*.so binaries, the GSM connection works.