3,678 karma · joined December 18, 2013
I mean, it's 3.7x larger than all the rest of the kernel (135x3.7=499), how is that in any way reasonable for such a small set of functions across so few devices to take up so much space?
Regenerating such static data from some master source, would be completely pointless, and would add pointless extra dependencies to the build process, and in this specific case, may likely not even be possible because of the proprietary nature of the off-topic tooling that may be required for effective management of the initial files.
---
In OpenBSD, NetBSD and other systems, there's actually a whole bunch of machine-generated files that are always part of the repository.
Things like build manifests (lists of all the binary files in the shipping product, e.g., distrib/sets/lists/base/mi) and pcidevs/usbdevs, are things that immediately come to mind:
https://github.com/search?q=repo%3Aopenbsd%2Fsrc+sync&type=c...
https://github.com/search?q=repo%3Aopenbsd%2Fsrc+regen&type=...
Avoiding bison/yacc parser generators as a build dependency, is another common case for the practice.
Personally, I'm a huge proponent of the practice. It allows you to reduce the complexity of the build system, increase the transparency on the history of the changes, and allows people to have a better understanding of where things are coming from, because you can directly find those things in the respective pcidevs.h / usbdevs.h, instead of wondering what is going on, and where those things are defined. It's a HUGE advantage.
I never understood why so many people are horrified at the idea of small amounts of the machine-generated code being manually committed straight into the repositories. It seems like they're incorrectly applying the general rule against such practice, ignoring the specific exceptions that are certainly most beneficial under the circumstances.
One of my favourite other examples is the self-documenting code. E.g., man-pages or test results. For example, maybe you use Go, and your man-pages are automatically generated based on the inline documentation within each go file itself. Committing such human-readable artefacts into the repository is a great idea if that allows everyone to immediately see what's going on with regards to the documentation, instead of having to run the code to see how it works. This increases transparency and code review efficiency, make it easier to promote the changes, because it's very clear to everyone what's going on, without having to reverse-engineer the code, or apply the patches and recompile etc.
Of course, if your whole idea is to hide things from management, and increase the complexity of the system to prevent the newcomers from catching up quickly, then such practices may indeed be detrimental.
Sorry, but it is absolutely and undeniably not!
I don't think it's accurate to portray AWS as the underlying infrastructure of the internet on the planet at all.
Speaking of the "planet", here's a sample statistics for .ru ccTLD on web hosting usage across the 1 million domain names in the zone — one of the top-10 ccTLD zones on the planet:
https://statonline.ru/metrics/hosting_shared?month=2021-12&t...
Amazon is dead last #30 with 0.46% of the market; the data is for December 2021, so, it's before any payment issues that would only originate in March 2022, and which would take weeks/months/years to propagate.
Hetzner is far more popular, at 4.11%, also, OVH is bigger than Amazon, too, at 1.38%, and even Wix had 2.16%. Even Google managed to get 1.15%, probably because of their Google Sites service. Most of the rest of the providers are local — that's how it should be if digital sovereignty is of the essence. The real reason for the local providers, however, is most likely affordability, reliability, price, better service and far better support, and not the digital sovereignty considerations at all. This is exactly why Hetzner is at the top, because the market is obviously price-sensitive if the unlimited venture capital was never available for the local startups, and Hetzner and OVH provide the best value for money, whereas AWS, does not.
The earliest data this service currently has, is for March 2020, and there, Amazon didn't even make it in the top-30 at all!
https://statonline.ru/metrics/hosting_shared?month=2020-03&t...
They have a separate tab for VPS and Dedicated, which covers about 0.1 million domain names compared to 1 million in the prior view, and, there, Hetzner, Digital Ocean and OVH, are, likewise, ahead of Amazon, too, with Hetzner being #2, having over 10%, compared to Amazon's 2%, with Amazon thus far behind:
https://statonline.ru/metrics/hosting_vps_dedic?tld=ru&month...
Numbers for 2025 don't look as good for any foreign provider, likely due to a combination of factors, including much stronger data sovereignty laws that may preclude most startups from being able to use foreign services like Hetzner, but Hetzner is still the most popular foreign option in both categories, still having more market share in 2025 than AWS did in 2021, and even DigitalOcean is still more popular than AWS, too.
BTW, I've tried looking up the BBC Radio 4 apocalypse claims, and I'm glad to find out that this information is false.
I'm glad you got your account restored, and I thank you for bringing the much needed attention to these verification issues, but I don't think you're making the correct conclusions here. Not your keys, not your coins. Evidently, this applies to backups, too.
The benefits can be huge, however. For example, many paywalls would stop working, meaning, you get to see the entire content without it being blocked by the paywall, because many paywalls are implemented through JavaScript, thus, they can't block anything if you don't have JavaScript.
It'd also block all those annoying cookie dialogs, too. You still have to be able to re-enable it per-site, otherwise, you won't be able to use many sites, because some require JavaScript for login/rendering and other stuff.
It should not be necessary to change the browser to view a website; people can just use archive.today, which works fine in all browsers with JavaScript, and doesn't require a captcha, either, in browsers that don't block stuff. (It only requires captchas in those browsers that do block stuff.)
That's only because the JavaScript is fast.
If you're using the Brave browser, you can click on the Brave logo when on the required site, and toggle the disable scripts button when on the www.theatlantic.com website, then JavaScript would be disabled for the site, and it'd stop requiring the paywall.
Please don't take these complaints personally; personally, not all of my devices / browsers have JS disable buttons, so, some of us do appreciate others posting the archive.today links, even for sites where paywall can be skipped through the script disable trick in some browsers.
Not every browser has the option to disable JavaScript for a webpage.
Yes, of course archive is necessary, as it helps everyone read the article easily, see https://news.ycombinator.com/newsfaq.html, which points out that complaining about paywalls is not.
Actually, they do not; but I'm not sure what's the heuristics. I've disabled all the protections in Brave for archive.today/is/ph, and not getting the captchas anymore.
I've only started getting them when moving to Brave in the first place.
It's only fair — if you block them, they block you.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/tor...
https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...
The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB.
There's actually another one in nbio that's 16MB:
https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...
The sys.tar.gz from https://ftp.eu.openbsd.org/pub/OpenBSD/7.7/ (normally unpacked into /usr/src/sys on an OpenBSD machine) represents the entire kernel source code of OpenBSD 7.7. (The userland and compiler are in src.tar.gz, Xorg is in xenocara.tar.gz, and ports are in ports.tar.gz.)
It has grown to 634MB unpacked for the entire kernel source tree.
But the vast majority of this growth is attributable to the sys/dev/pci/drm/amd directory, which is AMD Direct Rendering Manager, standing at 499MB, with the include files at sys/dev/pci/drm/amd/include being 458MB, the biggest of which is the asic_reg directory.
499/634 is 79%.
It follows that 79% of OpenBSD kernel by source code is dedicated to AMD's DRM implementation. Note that we're talking about the source code, NOT compiled code.
It's a huge part of Linux, too, over at drivers/gpu/drm/amd/include/asic_reg:
https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...
In OpenBSD, the last release before the explosive growth, was OpenBSD 6.5 (Apr 2019) with sys.tar.gz at 20MB. With OpenBSD 6.6 (Oct 2019), it went to 30MB, now with 7.7 (Apr 2025) it's 64MB compressed.
It's literally far more trivial than you may think. (At least if you already own a VPS or a dedicated server.)
Basically, (1), add a git user, (2), configure .ssh/authorized_keys, and that's basically it!
To add a bit more security, you may also want to edit /etc/shells and add git-shell as a login shell, then change git user to use that shell, but that's entirely optional (and it'd actually make it less trivial to create add extra repos, so, for a single-user repos, you may want to delay doing that).
In all, the entire set of official instructions can be printed on like a single double-sided Letter / A4 piece of paper.
P.S. Actually, I guess it's 3 single-sided pages, but that's only because you'd be printing the example SSH key twice, which takes a quarter of an A4 each time, thus, the entire official instructions take almost 3 single-sided pages total.
https://www.tomshardware.com/software/cloud-storage/aws-accu...
> Update: August 5 7:30am (ET): In a statement, an AWS spokesperson told Tom's Hardware "We always strive to work with customers to resolve account issues and provided an advance warning of the potential account suspension. The account was suspended as part of AWS’s standard security protocols for accounts that fail the required verification, and it is incorrect to claim this was because of a system error or accident."
This shows a bigger part of this problem.
When these mistakes do happen, they're invariably treated as standard operating procedures.
They're NEVER treated as errors.
It would appear that the entire support personnel chain and PR literally have no escalation path to treat any of these things as errors.
Instead, they simply double-down that it's NOT an error that the accounts was terminated on an insufficient notice over bogus claims and broken policies.
It basically has everything you need, and is Long-Range, too, without having to decide whether or not you want a mutually-exclusive "technology package" or "XXX package".
Without having to decide a whole bunch of other things, too, which, if you don't get, won't give you the advertised features seen in commercials, and if you do, won't keep the advertised price of the car.
Ports tree in general is a great way to install third-party software, but not necessarily for Xorg.
You still install KDE or GNOME through ports/packages on both systems, but X being more tightly integrated with the base system has benefits in reducing complexity for the rest of the components.
This was especially notable at BSD-wide events like BSDCan, AsiaBSDCon, EuroBSDCon etc.
OpenBSD supports suspend to disk, whereas FreeBSD does not. (Is this being changed as part of this laptop project?)
OpenBSD has always supported graphics, sound and other desktop things in the default kernel, without having to tinker with kernel config or loadable kernel modules. FreeBSD? http://cr.yp.to/unix/feedme.html
Also, on OpenBSD, the basic X is part of the base system, in the xenocara repository, and it basically just works, straight from the default installer:
https://en.wikipedia.org/wiki/Xenocara
OpenBSD actually does NOT support loadable kernel modules at all, and you're strongly discouraged from running a customer kernel, too. This has a side effect that both graphics and sound works out of the box, since deviation from defaults is discouraged, and if it didn't work by default, it'd not be recommended in the first place.
On FreeBSD, even the most basic X stuff is part of the Ports tree, which basically implies that most installations wouldn't have it, and it's often far less integrated, and requires way more tinkering, than xenocara on OpenBSD. For example, when you know most of your installations wouldn't have X, would you have graphics and sound support in the default kernel, or would that require further tinkering of the kernel config and/or LKM?
(On both systems, you still install KDE and GNOME from ports/packages, if needed, it's only the lightweight basic X and WM stuff that's part of OpenBSD base xenocara.)
So, even though FreeBSD is faster and more popular in many ways, to most people's surprise, OpenBSD actually has better laptop support.
He first points out that a royalty-free format was actually better than the patent-pending alternative that he was responsible for pushing.
In the end, he concludes that the that the progress of video compression would stop if developers can't make money from patents, providing a comparison table on codec improvements that conveniently omits the aforementioned royalty-free code being better than the commercial alternatives pushed by his group.
Besides the above fallacy, the article is simply full of boasting about his own self-importance and religious connotations.
Such a huge catch that the companies that offer you a royalty-free license, only do so on the condition that you're not gonna turn around and abuse your own patents against them!
How exactly is that a bad thing?
How is it different from the (unwritten) social contracts of all humans and even of animals? How is it different from the primal instincts?
Basically, the description for a healthy pescetarian diet that these studies are using.
I'm a developer with a project they use, so, I thought, for sure someone would review my resume after applying on their website. Nope.
After being ignored for a while, even having to get a Master's degree because no offers after a Bachelor's, I finally emailed a Director, who was previously a fellow committer at the project. People under him were not hiring at the time, but a recruiter from a different group has contacted me shortly, and I've had a 2-day flyout onsite arranged for two different positions, and had offers to join either one.
I've mostly stopped applying to the big companies long time ago (10+ years) precisely because I'd never hear back regardless of the match or the credentials.
The only exception has been JaneStreet — they've contacted me almost immediately after a cold application with a small cover letter about my interests.
Yet going the referral route, it's relatively easy to get an interview almost anywhere, even Google or Apple.
Wait, so, if it was a friend-of-a-friend situation, why did you not try to get a referral?
I've stopped applying to the big companies long time ago precisely because I'd never hear back regardless of the match or the credentials (the only exception has been JaneStreet — they contacted me almost right away after a cold application), yet going the referral route, it's relatively easy to get an interview almost anywhere.
I don't think most people actually have a solid understanding of what is and is not affected by which tariffs.
If I understand correctly, most of the tech stuff is effectively exempt; and Canada/Mexico tariffs don't apply to most items that are covered under "the rules of origin" certifications under USMCA (the successor to NAFTA).
I think the biggest hit has been the elimination of the de minimis rule, which now makes it difficult and/or impossible to get anything directly from China by USPS, be that cheap clothing or small electronics.
Wouldn't the value of the security guarantee in this scenario be a negative one for Taiwan?
Did you use v12 or v13 FSD? I've used v12 last year (which is far behind v13, and yet more behind robotaxi). I'd enable it as soon as I'm out of the garage, and it'd safely drive me right to the destination.
How exactly is that not "Full"? Why would they call it anything else when it can drive itself from point A to point B without any interventions most of the time?
So, you want someone to write a guide, but you admit you're not gonna read it or click on any affiliate links, because you'll just get that info from ChatGPT?
I think this is a problem we're gonna have with the AI age.
If the only consumer of information, is AI, who will be watching the ads and clicking the links to support all the content production?
You can't just keep ignoring the "Supervised" bit as if it's not there. Just because you think it's a stupid name, doesn't make it a lie. Have you even tried it yourself? I've tried v12, and it's amazing. It does fully self-drive. Why would they call it "mostly" if the idea has always been that it'd be "full" when it's done and out of beta? And as robotaxi shows, it's literally almost there.
I've just tried searching "FSD site:tesla.com" in Google Search, and basically every single result is "Full Self-Driving (Supervised)", with very few exceptions.