HN user
The vast majority of intelligence assets are analysts or sigint, not James Bond-ish operators who can discard identities and their family/friend/etc like a Scooby Doo mask. This is not a plausible thing.
This _is_ Silverblue and other ostree-based repos.
This article is focused on containers because when the root OS is immutable, then mutable developer workflows/etc necessarily happen in containers (distrobox, toolbox, whatever). OSTree is/was commonly described as "git for filesystems". Every update is an entirely new system image which applies a 3-way diff. It's possibly to state in a single command "show me the drift in my config files/data versus the ref I'm running" and/or "show me the diff between my running system and an update I may apply".
There is a stark difference between a sovereign power gagging or stifling perceived dissidents and other citizens (whether they are elected officials or not) deciding you're an unethical asshole others should be warned about.
What happened to Nixon? What happened to OJ Simpson from the victim's family?
And the advantage of doing this over letting application authors maintain their own packages and deptrees with flatpaks/appimage/whatever is...?
They could be based on top of Nix. In practice, it's more likely they'd be based on top of rpm-ostree. But that doesn't do anything to close the gap between the wild west of copr/ppa/aur and "get your application accepted into mainline repos" for someone who wants to distribute their app.
The goal of systemd as an *init system* is not the same thing as the goal of some of the systemd umbrella projects, and they shouldn't be conflated. systemd as an init system is leaps and bounds ahead of sysvinit, openrc, and upstart for distro maintainers, large scale sysadmins, etc. No more need for supervisord, random scripts to flag off and on was part of VPN connection, convoluted "meta" scripts which carefully restart 5 different services in the same order and a huge mess of shell.
That said, no, Lennart did not/does not do things that way on his personal laptop. His position is that users shouldn't need to know how to configure dnsmasq to have a local caching DNS server, that 99% of the options for dhcpcd aren't used by 99% of users (who are perfectly happy to simply get an address in a fraction of the time), that most users don't need to know how to configure /etc/sysconfig/network-scripts/ifcfg-* or /etc/network/interfaces/* for their use case.
If you do, you can disable those things. You can think this is a good opinion or a bad opinion, but at least he's pushing towards some kind of solution which isn't "RTFM". If you think his ideas are bad, propose new ones. Start a project which does it better. "Just don't change anything" is not a meaningful or productive way to design software or operating systems.
Snaps/Flatpacks/other binary-containerised stuff is one of the major reasons why I abandoned Linux distributions after 22-odd years (1999-2022), and am now a happy Apple user (the other one being abandoning X11 in favour of Wayland, and a switch to laptop-first usage, on which Linux still has horrible power-consumption).
Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside something in /Applications/... The .app is a folder, with all of its deps.
Linux distros have a history of abandoning useful, well-understood technology for fads that then cause power users all kinds of headaches later-on (e.g. by cluttering output of useful tools like mount). Eventually, power users just lose the will to adapt, and move on.
"Power users" have a history of complaining about distro maintainers abandoning useful, well-understood techology because the "power users" don't actually understand the technology, nor do the understand the enormous headaches it causes distro maintainers to put a sane face on 30 year old design philosophies and continue moving forward.
The goal of distro maintainers is to STOP investing endless man hours in trying to make X work with high DPI displays, scaling, high refresh rates, a fundamentally insecure design model, and so on. The goal of systemd is/was for distro maintainers to STOP wasting endless man hours on edge cases because sysvinit didn't have reasonable mechanisms for "if anything in this dependency chain is restarted or changed, re-evaluate it" or "don't try to start this service if the mount isn't available so systems stop hanging on startup if some NFS server isn't available" or whatever.
In the time of Jenkins et al the burden of creating bistro-specific packages is negligible.
Under the assumption that they are ABI stable, which is a bad one. Otherwise, it's the same old kaleidoscope of mapping out whether it's `libfoo-dev`, `libfoo-devel` for build requirements, whether it's a distro with a completely different naming system, dissecting the ELF header or reversing depchains in Python/Node/whatever to try to find deps and what THOSE are named in some distro, or whether they're even packaged at all, then building for every possible supported version of RHEL, Debian, Ubuntu, Fedora, SuSE, and down the line.
This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins."
Flatpak/Snap are essentially a re-invention of putting things in /opt and using LD_LIBRARY_PATH or chrooting. Disk space is much less of a concern than it was before, and sacrificing a little space to AVOID the mess of shit above is a good investment.
Yes, because either you, the user, must track down .NET Framework X.Y (less of a problem now that they're stabilized) or because the application packs all of it dependencies and shoves them into \Program Files or \Windows\System32 until it's eventually 30gb with 1000 copies of msvcpXXX.dll
That's not that different from the distribution model of Flatpaks/AppImage (or APK, or .app on MacOS/iOS). It's more that, traditionally, Linux packaging solutions try to only have ONE copy of glibc or any other library, and packages are recompiled from source so the symbols resolve. Something which isn't an option on Windows, as a generality.
It's just as likely that it's "TODO: add handling for this case which is out of scope during design and which no user is likely to ever request, because the developer argued that it should be there and got shot down"
Virtualize it and pass through USB devices to the VM for the microscope camera/etc.
Silverblue is intended for the opposite of that. It is single system image mostly immutable root OS. The goal is to *not* tinker with the core OS, and do your tinkering in containers (toolbox, distrobox, whatever).
Complaining that rpm-ostree took 2 minutes to update 2 packages (rpm-ostree downloaded an entirely new pre-baked filesytem snapshot and applied it atomically) is completely missing the point, as is complaining about selinux after swapping out a bunch of system level stuff. This is like the antithesis of the use case for Silverblue, and an author who has somehow never had to build a package for anything but Arch (deb would be much worse) complaining about the difficulty of building RPMs to install/overlay on the host system, which is not the intended use case *anyway*, is silly.
Count backwards. Sixty-one years left on a 75 year lease. It was in the middle of the 2008-2010 crash, and the city was facing massive budget shortfalls. They also leased Midway: https://www.reuters.com/article/chicago-parkingmeters/chicag...
This is around the same time that PA tried to lease their turnpike, and cities all over the US were facing a post-boom hangover when projected revenues from permits and property taxes didn't align with budget realities.
I'm not defending the decision, but it was far more shortsightedness than corruption.
A article from the relatively neutral Times of London which suggests a deeper investigation into whether the treatment of patients may be biased due to financials is neither anti-trans nor culture war.
This falsehood needs to die.
It's true for non-trivial cases, and exceptionally false for some things. Like databases. A lot of the sysctl tuning for large database environments has to be done on the host, either directly, allowing unsafe sysctls and restarting kubelet, running with privileges, etc.
This is not "independent of the underlying infrastructure" or "the VM and my laptop have the same kernel tunables set". They don't. And it matters.
Why is your project changing the license, and why do you assume that contributors would still have done so under whatever license you're changing to?
Because sometimes you have multiple, discrete applications which should be isolated, but need high performance (40gbe, optane, huge amount of CPU concurrency, whatever) and don't want to slice up the server for virtualization or run it in the cloud. Or you won't want to manage multiple pgpool/pgbouncer configs. Or you want BGP-based site failover and it's more complex with more clusters, or replicating massive data warehouses/ML data/preprod is substantially faster if it can be a job on the same server instead of replication, or...
How do you feel about "bad faith"?
This isn't a "JS" problem. A consistent story/UX around common tasks isn't "bloatware". Queuing jobs on the backend, managing CRUD-ish stuff like native objects, multi-part file uploading (including CORS management, storage as blobs in the DB if you need it), user/auth management, sending mails, and so on really is just the basics.
Of course you can a la carte your own solution together every time, but the API at every different layer is almost guaranteed to be markedly different, the level of testing, support, size of the userbase/ecosystem is unknown, and every minute you spend debating those solutions, wiring them together, maybe creating abstractions so the API "feels" more native, etc is time you are *not* spending writing the actual application.
Finding other developers to work on your homegrown potpourri who won't screw up because they don't fundamentally understand object storage or DKIM constraints when sending mail or can't optimize a query better than the ORM or whatever will be difficult, and even harder if you want to find one who can do that AND nail down which parts of the underlying infrastructure (k8s, DNS, message queue, distributed k/v store, whatever) may or may not be responsible for a problem surfacing for 3% of your users is a harder and harder ask.
You're free to consider DRF and backend Rails and .NET and the rest to be "bloatware". I am not a web person in any way, so I don't have a horse in this race, but I am/was a backend/infrastructure person who has repeatedly had to help "full stack" web devs out of shooting themselves in the foot because they don't understand OIDC/SAML or service lookups in k8s or service meshing or DNS between geo-distributed clusters or how to write an INNER JOIN or you name it.
The "bloatware" lets web devs ("full stack" or not) concentrate on solving their actual problems instead of spending time and getting behind schedules re-inventing comprehensively solved wheels.
`containerd` invokes `runc` (and `docker` can also invoke `containerd` via its API, which then invokes `runc`). The "lower level container runtime" is cgroups and various kernel namespaces (primarily process and network, but some others are included). There's no magic there.
They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".
The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.
GWB rebranded it as Climate Change, not anybody else.
Solar forcing is completely accounted for in the models, in all areas (albedo, bouncing in the galactic plane, distance from the Sun).
The repeated cries of "but you didn't account for this or that, which I know as a layman, but surely PhDs in climate science didn't think about!" is inane. It's in the models. Every single variable you can name and then some are in the models.
Climactic periods are not "measured" in any kind of arbitrary 3 decade cycle. Even if you want to pretend that they are, and we are returning to some kind of baseline (which every bit of science says we are not -- we are going to dramatically overshoot it), humanity did not evolve under those "historical norms". Our society and agriculture and population patterns did not emerge under those "historical norms".
Returning to those "historical norms" will mean the largest population migration in human history, with a large amount of it from nuclear states which already have shooting skirmishes in their borderlands facing an existential crisis over water (India, Pakistan, China). Those "historical norms" are not necessarily compatible with civilization.
Before you talk about how much farmland it is going to "open", ask yourself how well the supply chain did during COVID. Then ask yourself what will happen to it during a population migration. Ask yourself what happens when deep water ports at low sea level start having problems, and how we would get crude to refineries to get bitumen to even make asphalt to create infrastructure in the new "open" land, how we'd transport concrete and steel there if there are interruptions in the supply chain which impact diesel production. Ask yourself how long it will take to transform old-growth forest and granite-filled glacial retreat zones in Canada into arable land, how easily we'll be able to get chemical fertilizers, etc.
Even if you want to talk about how this is some kind of "historical norm", the question ultimately becomes not "is this anthropogenic?" (it is, but it doesn't matter), but "how do we intend to survive this as a species?"
This is pretty ridiculous. The "so-called 'experts'" are... journalists? Zero of these are studies. Zero. None. Nada.
There's the Guardian: https://www.theguardian.com/environment/2004/feb/22/usnews.t...
And Breitbart: https://www.breitbart.com/the-media/2015/06/01/media-fail-no...
And a bunch of other nonsense. Every one of these "predictions" is either a journalist trying to sell copy by exaggerating a story, or conservative media outlets clapping themselves on the back for pointing out that journalists who exaggerated were wrong.
None of these "predictions" are in any way science, and all of the climate modeling in the past 30 years has made predictions which are *more conservative than reality*.
I understand that, but adult ADHD and childhood ADHD are very different.
The energy level in childhood, brain development, behavioral expectations in school, and everything else is very different. I'm old enough that ADD (now ADHD) wasn't really a thing when I was growing up. People had to learn to manage, without medication. Doing it with medication is different, but being a functioning adult is not the same, and the same knowledge should not applied.
Everything you are saying is from an outside point of view. He sounds depressed, but he went through a traumatic incident. That doesn't mean he cannot have both.
It's not even a little surprising that he had a change in personality. You sound extremely judgmental, to be honest. Your friend went through trauma. He may not have PTSD (that word is used a bit too freely these days), but it was a traumatic experience which sounds like it literally crippled his ability to do half of the things your'e saying he doesn't "want" to do.
He suffered "life long damage to his dominant hand". The hand he presumably uses to help fly the drone, to play music, to use the controller playing games, to use the mouse in Blender (maybe). It may be painful constantly, especially if the rehab/physio was hard to manage during lockdown. You would also have a "large change in personality".
There isn't a lot of psychiatric care which can be done in isolation. People who have ADHD/ASD are also more likely to be depressed, but you can't "root cause" this to a single issue, and saying "well, he's depressed/has trauma, so he should deal with that" doesn't mean he does not also have ADHD.
He is trying to tell himself to "fake it until he makes it" after a traumatic experience, and he does not want to relive the trauma in therapy, he does not want to risk whatever potential side effects from antidepressants.
He is trying to accept that this is his life now. This life of lifelong damage in his dominant hand which has forever put the thing he loves out of his reach, and _maybe_ dragging him out of the house to do new things would introduce him to something new he loves which does not remind him of the life he cannot have anymore. _Maybe_ doing that instead of gossiping with his wife about it and wondering why he no longer does his old hobbies would help.
It sounds as if he is living in limbo between a life he lost and finding new fulfillment. The thing about very traumatic experiences as an adult is that the medication he is currently on (and again, which he probably needs) has made his life somewhat bearable again. He doesn't sound happy, and he doesn't sound like he knows what will make him happy, but the current state of things is so much better than it was two years ago that he doesn't think it's bad, or he worries that making more changes would make it worse again.
Be your friend's friend instead of whatever you're doing now. Monday morning psychiatrist on HackerNews is definitely not.
My personal opinion is they have untreated PTSD following a violent animal attack in early 2020 that caused life-long damage to their dominant hand. This in turn led to them suffering panic attacks around animals, anxiety due to the Covid lockdowns making treatment/physio complicated, furlough leading to isolation at home and being unable to do many of their hobbies from the physical injury (unable to play video games, the guitar, drums, etc)
You answered your question. I was diagnosed later in life, as a successful engineer. I am not and never was at the "unable to concentrate on a crossword" level, but you seem to have some misunderstanding about what ADHD is. It is not the inability to concentrate on things. It is the inability to concentrate on _appropriate_ things. It's perfectly possible for them to just be completely disinterested in the crossword, yet able to be engrossed for hours in something which interests them. The medication levels this out so you are able to keep your attention on mundane tasks and complete them after the "interesting" part is over, or to start on mundane tasks at all instead of procrastinating until it's do-or-die.
Fundamentally, there's a strong intersection with the dopamine reward system, and a "history of drug misuse" and poor impulse control is completely in line with a diagnosis.
Personally, I went through a close family member's suicide, followed rapidly by moving across the country to an isolated town where my spouse developed a problem with alcohol, a couple years of abuse, a divorce, another move to a different area of the country, then all of the lockdown stuff. All of my (and their) unconsciously constructed support structures, reward activities, and safety nets evaporated. Stop.
This honestly isn't that surprising. It's not incompatible per-se. Linux has plenty of ABI-incompatible kernels (-rt, -ck, -pf), plus the assortment of forked kernels which never had changes merged back into upstream for various embedded boards, intel's fork for feature development, the same for network, and so on.
One of the "big" guarantees Red Hat customers like RHEL for is that they will not break kernel ABI through a release cycle. They like this because it's really hard to do, and even very minor dot releases of the kernel provide no assurances that the ABI won't break.
This seems to be normal distro stuff, and the problem broadly seems to be in two parts: * The Illumos team and distros need to either figure out a better mechanism for indicating minor kernel versions than the old "patch release", or they need to actually pay attention to it now that they know things diverge sometimes. * This worked fine when building from source. The assumption that all of the IllumOS distros can freely share binary packages seems to be a bad one, and they may need to go to the same process as every other distro and actually... rebuild.
The UNIXes of the 80s/90s had far less in common than this. They had a shared root, but diverged very far in terms of userspace and kernel.
We know the answer to this, and it was... the Egyptians. The mistake the earlier Egyptologists made is exactly the same one you're making here, which is that history is some kind of inevitable march towards progress where knowledge and skills are never lost, and we never go backwards.
There's firm archaeological evidence around quarry sites, etc.
The same (pretty nonsense) questions could have been asked about Roman concrete or how tunnels were bored through the Apennines for aqueducts or whatever else you feel like during the late Middle Ages, despite the fact that the demographics of Italy hadn't really changed. The gap in time between Khufu and Ramses is basically the same as the gap between the reign of Augustus and the Hundred Years' War.
I'm not a GPU expert: what other characteristics other than performance are there to consider when deciding value? Intuitively, it seems like if something is twice the performance and less than twice the price, it is a great value.
It's not a great value when it's nearly twice the price and double the performance two years later. It has been reasonably common to get 50% or more performance increase between generations for the same price, and rebranding a XX70 as a "4080 12GB" to increase the price doesn't change that. It's also unusual for a XX80 to be "nearly double the price" even a generation later.
The pricing is out of line with what would historically be expected, as is having a completely different die.
Consider that languages don't develop in isolation, and both the pre-conquest inhabitatns of the Isles and the Saxons had regular interactions with the Norse, where its religious/spiritual connotations could very easily have just become a cognate.
This isn't really reality-based. There are/were a bunch of problems, but it's not these.
- Redhat kneecaps centos because some mid manager was worried he might not get this years bonus
Red Hat paid (pays, probably) bonuses quarterly, and they were (are, probably) based on stock performance. They are not and never were based on cost saving measures.
The reality is that, probably, CentOS should have never become part of the "Red Hat family". The Chinese firewall concept didn't really work internally, the vast majority of RH engineers ran Fedora anyway, and it was basically just giving CentOS better build infrastructure plus giving customers a way to buy their way out of nonsense situations. The Red Hat support agreement always said "if you're not running RHEL, we'll close your case", which frequently meant customers who ran CentOS in dev/qa/preprod and RHEL in production who were forced to install another RHEL system (which RH made no money on anyway, since they never charged license costs, only subscription fees for updates) just to reproduce an issue so the sosreport didn't say "CentOS Linux ...".
In general, the same engineers who worked bugs (or were escalated to cases) on RHEL were often part of the community of upstream maintainers anyway, and RH's policy was "upstream first, and if it needs an emergency downstream bandaid, take it out once upstream accepts a patch and backport it properly", but it was easier for customers to get attention on problems if they could back it with dollars.
Rocky, Alma, and OEL (however you feel about that) exist anyway and basically picked up where they left off. Stream probably always should have been a thing. It was (probably is) an enormous amount of work to branch, re-sync, and generally re-sync again any given Fedora snapshot to a new RHEL release, and getting it into shape was (probably is) a nightmare, because the difference between the code which is currently running on any given RHEL release and what upstream is is huge. sysvinit -> upstart/sysv -> systemd, for example.
- Redhat kneecaps Ansible by making ansible-core and forcing everyone to re-install community plugins they were using from EPEL, or buy the shiny Redhat version of ansible.
The Ansible leadership was generally terrible about open source philosophy regardless. This is nothing new.
- Redhat decides to turn Ceph into yet another garbage storage product with the same exorbitant support fees and contract payments that were the original motivation for an open source storage solution in the first place.
Open source Ceph still exists. I don't see the difference here. It's just moving it from one independent company to another independent company, at least nominally.
The systemic problem with IBM acquiring Red Hat was in a lack of good answers for many of the questions employees had (policies on open source, WFH, etc), the fact that the purchase was not communicated even to management until news articles broke, a six month cliff for "business critical" employees, and following that, the fact that IBM fundamentally believed that they could do what everyone always thought Red Hat was doing and drive the market, so they were constantly pouring money and engineers into projects that had no chance to succeed in the market rather than adopting and fostering upcoming solutions, and *that* drove engineers out of the company very rapidly.
I'm not sure why you think anything has changed, in any sport.
They are eating too much, and their regulation of hunger impulses is out of whack.
There are essentially zero studies which show subjects on a controlled diet under observation having more than a +/-5% different in metabolic efficiency. The burden of proof is, frankly, on those who are looking for anything except for overconsumption as the cause.