Hacker Newsnew | past | comments | ask | show | jobs | submit | andreyv's commentslogin


Autoconf can use cache files [1], which can greatly speed up repeated configures. With cache, a test is run at most once.

[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...


Sadly the cache files don’t record enough about the environment to be usable if you change configure options. They are generally unreliable.


Here is a non-zero null pointer: https://gcc.godbolt.org/z/Po5r5Pa36


whats going on here, I dont know enough C++ to understand


It creates a compound literal [1] of type array of int, and initializes the specified array positions using designated initializers [2] with the results of calls to puts().

Using designated initializers without the = symbol is an obsolete extension.

[1] https://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html [2] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html


Even the original version 1507 is still supported on the LTSC channel. Support for UTF-8 manifest was added only in version 1903.


Old does not mean bad. Even a decade later Wayland struggles to provide basic features that were built in the X protocol.


When rewriting apps, people have a tendency to say: "well, Oldversion provides X. We could make a Newversion that provides X better, but that's hard so maybe X is actually bad? We should provide Y instead." Then they're confused when nobody with X needs wants to use Newversion.


Which ones do you have in mind? I don't miss X in the slightest.


Xmodmap


It's OK to use X until Wayland has support for the missing features. I don't really care what I'm running. But it's clear that X is not in shape to see significant development (e.g. to support new needs) in the coming decades.


The number of registers available to the program is fixed in the instruction set. The program cannot address more registers without recompiling it to an extended instruction set.


First person shooters. Vertical synchronization causes a noticeable output delay.

For example, with a 60 Hz display and vsync, game actions might be shown up to 16 ms later than without vsync, which is ages in FPS.


Key word here being "might". What actually gets displayed is highly dependent on the performance of the program itself and will manifest as wild stuttering depending on small variations in the scene.

I've seen no game consoles that allow you to turn vsync off, because it would be awful. No idea why this placebo persists in PC gaming.


The Soviet Union briefly tried 5 and 6 day weeks in the 1930s: https://en.wikipedia.org/wiki/Soviet_calendar


You can use systemd-cron [1] to run traditional cron jobs with systemd. No need for a separate daemon anymore.

[1] https://github.com/systemd-cron/systemd-cron


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: