Eight Bit
Hardcore Member
I have both the 1541UII as well as a U64. It makes C64 life so much more convenient...
Tell that to my Pandora... it's getting drunk every day now...
That's why I use noscript, so I don't have to spend any cycles for google or facebook etc. to track me, or spend any cycles beyond displaying a simple image on you advertising to me.I did not find those 2GB videos to be persuasive since they didn't simulate real browsing. They just loaded a bunch of pages and did not portray interacting with them.
For web application use, 2GB is the bare minimum today, particularly if you use Firefox with JavaScript.
I plan to get another CPU board in around 2 years. By then I'll have a much better idea of whether 2GB is enough or not.You will hate yourself 2 years from now if you don't get 4GB.
Well "They" as you put it would be me, I spent a couple years using that OMAP5 devboard as a primary workstation on my electronics bench, it handles web browsing fairly well, I typically only have a half dozen of tabs open even on my powerful desktop. I find anymore open at once is a distraction. A 2GB OMAP5 would be fine for just everyday browsing, it's a handheld a typical sane person doesn't need 20+ tabs open at once, bookmarks exist for a reason. Some observations I have, so I'm running 64-bit x86 Debian Stretch with MATE on my desktop, for some reason it's using ~800 MBs just idling at the desktop no windows open, no background services. Running 32-bit armhf Debian Stretch on the OMAP5 devboard with MATE idles ~80-100MBs of usage. So in my opinion 2GB goes farther in an armhf environment.I did not find those 2GB videos to be persuasive since they didn't simulate real browsing. They just loaded a bunch of pages and did not portray interacting with them.
For web application use, 2GB is the bare minimum today, particularly if you use Firefox with JavaScript. You will hate yourself 2 years from now if you don't get 4GB. The Pyra CPU is already quite outdated so why make yourself have to worry about another performance bottleneck?
The power draw in normal use (ie with the screen on) between the two will be minimal.
If you are not someone who uses lots of browsing tabs or virtual machines, then 2GB wouldn't be so irritating.
Some observations I have, so I'm running 64-bit x86 Debian Stretch with MATE on my desktop, for some reason it's using ~800 MBs just idling at the desktop no windows open, no background services. Running 32-bit armhf Debian Stretch on the OMAP5 devboard with MATE idles ~80-100MBs of usage. So in my opinion 2GB goes farther in an armhf environment.
Well "They" as you put it would be me, I spent a couple years using that OMAP5 devboard as a primary workstation on my electronics bench, it handles web browsing fairly well, I typically only have a half dozen of tabs open even on my powerful desktop. I find anymore open at once is a distraction. A 2GB OMAP5 would be fine for just everyday browsing, it's a handheld a typical sane person doesn't need 20+ tabs open at once, bookmarks exist for a reason. Some observations I have, so I'm running 64-bit x86 Debian Stretch with MATE on my desktop, for some reason it's using ~800 MBs just idling at the desktop no windows open, no background services. Running 32-bit armhf Debian Stretch on the OMAP5 devboard with MATE idles ~80-100MBs of usage. So in my opinion 2GB goes farther in an armhf environment.
I want to disable the write cache system wide and force it to finish actually writing before telling me it is done (a whole other issue with current Debian). (Super annoying when using removable media.)
cp is done at that point, it returns because cp has exited and therefore all of its associated resources were freed. This is an independent feature of the kernel and its filesystem drivers.Whoever decided we needed to be returned to a prompt before cp is done needs to be ... ... scolded.
cp is done at that point, it returns because cp has exited and therefore all of its associated resources were freed. This is an independent feature of the kernel and its filesystem drivers.
Windows does the same since Vista.
There's so many reasons I'm baffled that you can't think of even a single one yourself... Block based devices (in this context the Pandora's NAND chip is the only thing that is not block based, even the eMMC chip of the Pyra is block based due to its internal FTL) can only access a whole sector at a time, which is a PITA if you're only performing small data transfers (especially on modern 2K sector devices), parallel accesses to the same range of sectors by multiple programs, access time optimizations based on the physical layout of HDDs by reducing head movement (NCQ), protocol-level optimizations that reduce the amount of transactions, exploiting synergies based on the device caches and cache-like structures like the SLC buffers in TLC SSDs...What *is* the purpose of this kernel write caching?
It's a mount option of the filesystem driver. Like every other mount option, you configure it in your fstab file.Is it useful for single-user low-write frequency systems? Can i disable it on certain devices? Like usb sticks and sd cards?
You can also simply run "sync". That won't return until all cached disk operations have completed.We have access indicator LEDs that show you when it's done writing,