Glad to see the Garden is back! This and Spoono were some of my favorite websites back when CSS-driven web design was bleeding edge and people were just starting to use lots of nested divs instead of lots of nested tables. The book was nice too.
Well, I know it's pretty easy in Debian. (It's not completely pain-free if you need unpackaged third-party libraries and/or if you are cross-compiling from one uncommon architecture to another.)
> What's the state of the art for cross-compiling in $CURRENTYEAR?
Poopy garbage dog poop.
glibc is a dumpster fire of bad design. If you want to cross-compile for an arbitrarily old version of glibc then... good luck. It can be done. But it's nightmare fuel.
tbh I haven't gone too deep because glibc is such a standard :(
but I can answer with reasonable confidence "musl surely has other problems, but not this one". It's a nice, clean, simple, single set of headers and source files. Very nice.
Well there's two flavors to this. Building glibc and building a program that links against glibc. They're not entirely the same. And you'd think the latter is easier. But you'd be wrong!
It should be trivial to compile glibc with an arbitrary build system for any target Linux platform from any OS. For example if I'm on Windows and I want to build a program that targets glibc 2.23 for Ubuntu on x86_64 target that should be easy peasy. It is not.
glibc should have ONE set of .c and .h files for the entire universe. There should be a small number of #define macros that users need to specify to build whatever weird ass flavor they need. These macros should be plainly defined in a single header file that anyone can look at.
But glibc is a pile of garbage and has generated files for every damn permutation in the universe. This is not necessary. It's a function of bad design. Code should NEVER EVER EVER have a ./configure step that generates files for the local platform. EVER.
>glibc should have ONE set of .c and .h files for the entire universe. There should be a small number of #define macros that users need to specify to build whatever weird ass flavor they need. These macros should be plainly defined in a single header file that anyone can look at.
Code generation aside, this is not really a great way to do it either. The build should include target-specific files, as opposed to creating a maze of ifdefs inside the code.
> The build should include target-specific files, as opposed to creating a maze of ifdefs inside the code.
Hard disagree. What makes you think it's a maze of ifdefs?
Compiling a library should be as simple as "compile every .c/.cpp file and link them into a static/shared lib". The nightmare maze is when you don't do that and you need to painfully figure out which files you should and shouldn't include in this particular build. It's horrible.
Far far far simpler is to stick with the rule "always compile all files". It's very simple to ifdef out an entire file with a single, easily understood ifdef at the top.
I do agree you don't want the middle of a file to be a fully of 10 different ifdef cases. There's an art to whether to switch within a file or produce different files. No hard and fast rule there.
Fundamentally you put either your branching logic in the code or in the build system. And given that source files should be compatible with an unbounded array of potential build systems it is therefore superior to solve the problem once in the code itself.
I am currently trying to get the Zig glibc source/headers to compile directly via clang and trying to figure out which files to include or not include is infuriatingly unclear and difficult. So no, I strongly and passionately disagree that build-system is where this logic should occur. It's fucking awful.
You're getting downvoted but you're not wrong. Well, it's not on purpose per se. It's just really really bad design from the 80s when we didn't know better. And unfortunately its design hasn't been fixed. So we have to deal with almost 40 years of accumulated garbage.
Indeed, that why HN comments are kind of dead (AIs, zealots with one billion accounts behind VPNs, etc). Sometimes I do still try to give an honest, but unpleasant, opinion/fact though. I should stick to raw neutral communication and information publishing.
I wanted to renew some domains with Gandi yesterday, and noticed that their prices increased a lot this year. This Reddit post is the only article I could find about it.
.com/.net/.org/.dev are all around $40/year to renew now, up from about $25 six months ago.
Tooling and code generation improvements no doubt help a lot, but IMO those improvements must be coupled with creative manual optimizations in order to get something like this out of a platform that was tailored for rectangular 2D bitmaps.
The 4A doesn't get security updates anymore though, right? The language on the website says "guaranteed until at least August 2023" so I guess it's up to Google's good will.
Do security updates really matter that much? May be they do depending on your usage patterns. I think anyone will be fine without most of those security updates. Also most of the slowdowns are caused by automatically updating apps which keep gaining weight with every update.
Yes, security updates absolutely matter regardless of your usage pattern. You could unwittingly visit a website that has been compromised to exploit a zero-day in your browser. Or receive a malicious text message. Or open a PDF. Or or or.
I do visit sites with a phone with latest firefox with ublock origin. Browsers get updates regardless whether android itself is updated to latest version.
I am not defending unpatched phones just to be clear, but its not end of the world if you use unsecure device, just keep all your money and other important stuff away from it. Which is fine for many people.
>You could unwittingly visit a website that has been compromised to exploit a zero-day in your browser.
In Android, browser, messaging app updates and many even system updates are delivered through Play store (long after system/OS updates have stopped for the phone), so attacks will have to be much more sophisticated.
Nobody that I know cares the least bit if they get security updates or not. Could be that it changes if there ever comes along a widespread exploit that won't get patched, but currently it's just not a concern especially for any non-techie.
This is a particularly badly-timed comment. Not even a month ago there was a 10/10 severity vulnerability in webp, including Chrome, that could let your phone get pwned by serving it a video, and people have confirmed it is being actively seen in the wild. Security updates absolutely do matter.
> I say buy the latest MacBook, expense it, factor it in as a monthly cost. These are expendable and essential tools. They pay for themselves
Yay, another top comment that steamrolls the posted article. I say don't buy the latest Macbook: instead repair, refurbish, and get true lifetime use out of these expensive devices. They're expensive to manufacture, expensive to buy, and expensive for our planet and people to just throw them away every year.
Thank you for your service defending the hot product of a profitable company against the criticism of everyday people, it's wonderful to have someone standing up for what is right.
Bingo, you should never pass arbitrary strings where they could be used as format specifiers, it's like running arbitrary code. Some compilers even issue warnings when you pass non-literal format strings to the printf family.
