This only requires that sizeof(long *) <= sizeof(void *). This allows you to convert anything to void*, and back (you'll just lose the extra unimportant bits).
Are you crazy? The Pi 3 was a massive upgrade. It switches to 64-bit Core A53 (a different CPU instruction set!!!), boosts CPU frequency by 300 MHz; RAM is twice as fast; and it has 802.11n WiFi and Bluetooth.
I'm still running XP at home, because I didn't give enough of a damn to go to all the hassle of upgrading.. and truth be told I didn't know about any 'telemetry' in Win7 anyway, but had I known I would've been pissed about that, too.
Maybe Ubuntu LTS or Debian? Beware that Ubuntu only offers security updates for their small main repository. Or something like CentOS; that will reduce your need to upgrade a lot.
Current plans are some flavor of Linux. When I get around to it. There's only one piece of software I have that has only a Windows-only version, and I can get around that easily enough.
Wine is also really great these days, it even runs a.NET app I threw at it, using it's Mono support.
This is basically right. The reads were always unbuffered, we just added a ReadLine() in 2011 - that was actually more efficient and read entire blocks at once and then seeked back if it read to much - but this broke pipes, so it was switched to read a single byte at a time.
Anyway, the code was a real disaster due to it's historic growth of adding various compression formats - but it is now nicely refactored, so we actually know what's going on, and can easily add new formats, buffers or anything we like.
There are multiple stages. A package can be unpacked (preinst script run and unpacked) or configured (postinst script run too).
Dependencies only matter for configuration, that is, running the postinst script. There are special predepends for the preinst script, but they really should not be used unless absolutely necessary.
The thing is that the postinst script might assume that any dependency is configured.
There are also breaks (configure time) and conflicts (unpack time).
APT also tries to respect dependencies where not needed, but it's not that strict about them.
We were practically calling read(fd, buffer, 1). We're not using standard C library I/O functions, but raw syscalls.
Our ReadLine() function does the same as fgets(), BTW.
Buffered reading my seem obvious too you, but the code in question had some users outside the class that worked directly on the file descriptor, and thus will not work correctly with buffered reading. Also, it's used in other code that implements its own buffering or does not need one, because it simply copies page-size blocks from one file to another.
As another example, I have not figured out how to do go completely buffered without messing everything up yet: test suite fails all over the place if I switch from syscalls read,write,etc. to fread(), fwrite(), etc.
Write buffering is especially weird: Callers now need to really make sure to actually flush the contents to the disk (or close the file), otherwise things will fail. As we cannot expect all callers to do that, we probably need to turn this into an optional flag.
Well, we do download in parallel if you use httpredir.debian.org and httpredir.debian.org returns different mirrors for different packages (which it does not do all the time, but reasonably often).
I don't like installing in parallel, or downloading and installing at the same time, as they just make the error handling harder, for modest speedup.
Gosh it was slow code. Not so much bad code. There are 3 people working on APT in their free time. Instead of complaining, do something about it. You can join #debian-apt on OFTC, view the commits live, and check them.
What matters more is that there are almost no functional regressions thanks to our test suite. Checking for performance regressions is an entirely different beast altogether.
It's not using standard I/O function, but pure syscalls, which are obviously unbuffered. And the same code paths are also used for other stuff that maps files.
Performance critical code implemented a buffer on top of that, and the ReadLine() function experiencing the main issue was only added as a convenience function and not used for anything critical until a few months ago (and we forgot that it was not optimized).
Anyway, we implement buffering for ReadLine() now. I'll try to make it generic for both reads (all reads) and writes, but so far have not succeeded, probably because some code depends on unbuffered reads or writes.
ELILO is dead and should not be used anymore.
"This project is orphaned, Debian dropped it in 2014, and RH & SUSE stopped using this tree (and feeding back change) long before that so no longer interested in working on it. Feel free to start your own source tarball is available."
Slashdot Mirror
This only requires that sizeof(long *) <= sizeof(void *). This allows you to convert anything to void*, and back (you'll just lose the extra unimportant bits).
Nexus 7 2012
Videos of Natalie Portman are blocked. It only allows you to watch Nathan Fillion.
Are you crazy? The Pi 3 was a massive upgrade. It switches to 64-bit Core A53 (a different CPU instruction set!!!), boosts CPU frequency by 300 MHz; RAM is twice as fast; and it has 802.11n WiFi and Bluetooth.
passw0rd!
I'm still running XP at home, because I didn't give enough of a damn to go to all the hassle of upgrading.. and truth be told I didn't know about any 'telemetry' in Win7 anyway, but had I known I would've been pissed about that, too.
Maybe Ubuntu LTS or Debian? Beware that Ubuntu only offers security updates for their small main repository. Or something like CentOS; that will reduce your need to upgrade a lot.
Current plans are some flavor of Linux. When I get around to it. There's only one piece of software I have that has only a Windows-only version, and I can get around that easily enough.
Wine is also really great these days, it even runs a .NET app I threw at it, using it's Mono support.
ThinkPad P50, P70 do, those replace the W series.
It is throwing away your vote, as Lessig is not running anymore.
Is'nt the stock dialer updated, and the Google dialer only adds lookups on top of it?
This is basically right. The reads were always unbuffered, we just added a ReadLine() in 2011 - that was actually more efficient and read entire blocks at once and then seeked back if it read to much - but this broke pipes, so it was switched to read a single byte at a time. Anyway, the code was a real disaster due to it's historic growth of adding various compression formats - but it is now nicely refactored, so we actually know what's going on, and can easily add new formats, buffers or anything we like.
Have you looked at Limba and/or xdg-app?
There are multiple stages. A package can be unpacked (preinst script run and unpacked) or configured (postinst script run too). Dependencies only matter for configuration, that is, running the postinst script. There are special predepends for the preinst script, but they really should not be used unless absolutely necessary. The thing is that the postinst script might assume that any dependency is configured. There are also breaks (configure time) and conflicts (unpack time). APT also tries to respect dependencies where not needed, but it's not that strict about them.
We were practically calling read(fd, buffer, 1). We're not using standard C library I/O functions, but raw syscalls. Our ReadLine() function does the same as fgets(), BTW.
Buffered reading my seem obvious too you, but the code in question had some users outside the class that worked directly on the file descriptor, and thus will not work correctly with buffered reading. Also, it's used in other code that implements its own buffering or does not need one, because it simply copies page-size blocks from one file to another. As another example, I have not figured out how to do go completely buffered without messing everything up yet: test suite fails all over the place if I switch from syscalls read,write,etc. to fread(), fwrite(), etc. Write buffering is especially weird: Callers now need to really make sure to actually flush the contents to the disk (or close the file), otherwise things will fail. As we cannot expect all callers to do that, we probably need to turn this into an optional flag.
Yes, of course it wil, it is currently in xenial proposed waiting for the autopkgtest to run.
Well, we do download in parallel if you use httpredir.debian.org and httpredir.debian.org returns different mirrors for different packages (which it does not do all the time, but reasonably often). I don't like installing in parallel, or downloading and installing at the same time, as they just make the error handling harder, for modest speedup.
Gosh it was slow code. Not so much bad code. There are 3 people working on APT in their free time. Instead of complaining, do something about it. You can join #debian-apt on OFTC, view the commits live, and check them. What matters more is that there are almost no functional regressions thanks to our test suite. Checking for performance regressions is an entirely different beast altogether.
I'm reading everything :)
It's not using standard I/O function, but pure syscalls, which are obviously unbuffered. And the same code paths are also used for other stuff that maps files. Performance critical code implemented a buffer on top of that, and the ReadLine() function experiencing the main issue was only added as a convenience function and not used for anything critical until a few months ago (and we forgot that it was not optimized). Anyway, we implement buffering for ReadLine() now. I'll try to make it generic for both reads (all reads) and writes, but so far have not succeeded, probably because some code depends on unbuffered reads or writes.
civilizations
ELILO is dead and should not be used anymore. "This project is orphaned, Debian dropped it in 2014, and RH & SUSE stopped using this tree (and feeding back change) long before that so no longer interested in working on it. Feel free to start your own source tarball is available."
Isn't it basically a netflix client with a browser around it? ;)
I scored 46
+1
It's between 0.5 to 1 day(s) more/less battery life, assuming the usual battery life of 2 to 4 days with the 3100 mAh one.