Yes, but also from an implementation perspective: if I'm making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:
One of our engineering teams who normally builds our products in-house was made to bid against contractors who promised the moon.
Them and multiple other teams then had to spend a total of 18 months getting the contractor's shoddy work up to scratch. When they were done, the lead engineers from three teams left, as well as their manager.
Memory safety is likely to prevent a lot of bugs. Not necessarily in the kernel proper, I honestly don't see it being used widely there for a while.
In third party drivers is where I see the largest benefit; there are plenty of manufacturers who will build a shitty driver for their device, say that it targets Linux 4.19, and then never support/update it. I have seen quite a few third party drivers for my work and I am not impressed; security flaws, memory leaks, disabling of sensible warnings. Having future drivers written in rust would force these companies to build a working driver that didn't require months of trawling through to fix issues.
Now that I think about it, in 10 years I'll probably be complaining about massive unsafe blocks everywhere...
I build Linux routers for my day job. Some advice:
your firewall should be an appliance first and foremost; you apply appropriate settings and then other than periodic updates, you should leave it TF alone. If your firewall is on a machine that you regularly modify, you will one day change your firewall settings unknowingly. Put all your other devices behind said firewall appliance. A physical device is best, since correctly forwarding everything to your firewall comes under the "will one day unknowingly modify" category.
use open source firewall & routing software such as OpenWRT and PFSense. Any commercial router that keeps up to date and patches security vulnerabilities, you cannot afford.
bcachefs; I currently use zfs and am not a huge fan of btrfs. Having another filesystem mainlined will be fun.
eBPF, particularly if somebody picks up after the presumably abandoned bpfilter.
Improved/matured support for rust written drivers. I'm not so fussed about in-tree work, but future third party drivers being written in a safer language would be a nice benefit.
long term: the newly introduced accelerator section of the kernel might make SoCs with NPUs and the like have better software support.
very hyped for plasma 6, and Cosmic both. I've got a lot of confidence in KDE devs, and Cosmic previews look very nice.
NixOS has been a really cool distro for a while, but it also looks to have a solid build system from which interesting derivatives will show up.
Any government which makes caffeine illegal must be prepared to enforce that law with mass violence, or let it be ignored.
Given how unlikely your average cop is going to enforce a law they regularly brea... Oh, nevermind. Yeah it'd be a shit show. Demonstrations, arrests, black markets, the whole nine yards.
NT is not the majority of windows code though; for windows to be multi architecture, all of windows needs to work with the new architecture; NT, drivers & userspace.
For Linux, if an existing userspace application doesn't work in aarch64, somebody somewhere will build a port. For windows, so much of their stuff is proprietary that Microsoft are the only ones able to build that port.
Not because "windows bad", just a consequence of such a locked down system which doesn't have anything open source to inherit.
Likely a combination of 4 things:
They have third party firmware in their blobs that they are under NDA regarding the source code.
They believe in the source code is a large part of their success and don't want to reveal it.
They believe giving out the source code will allow many inferior variants of the software, impacting their brand.
Control; the more source code they have in mesa the more of their code can be rejected by mesa. Keeping their stuff as blobs allows them to put in whatever hacks they want.
hat's a bad faith interpretation of "the people control the means of production".
I want you to consider the difference between the work needed to complete a task, and the work needed to manage a workplace: for one of those tasks, only the experts in that task can meaningfully contribute to the outcome, whereas for the other, everybody who is part of the workplace has meaningful input.
I don't know about your experience, but everywhere I've worked there have been people "on the ground" who get to see the inefficiencies in the logistics of their day to day jobs; in a good job a manager will listen and implement changes, but why should the workers be beholden to this middleman who doesn't know how the job works?
I've also had plenty of roles where management have been "telling me where to cut".
America isn't even the most democratic country in the Americas, but that's clearly not the point they're making.
If the title was "...end of world democracy" you'd have a point but given how much fascistic rhetoric and policy has increased around the world since trunpism it's fair to say many countries are following the US lead here.
Even if they don't, buying this game still goes in to lining JKRs pockets, something she has explicitly considered as validation of her beliefs.
The makers of the movies, and the publishers of the books also probably didn't all have anti-trans views, but they don't have to for JKR to use them to cause harm.
I get it, the devs of a good game don't deserve to be attached to her, but you've got to draw the line somewhere and this is where I've chosen to draw mine.
Until it marks you as unlicensed because you used a new motherboard.
Sure, but that's not necessarily a bad thing; if the Linux version is missing useful output that would be bad, but if the DX to Vulkan translation ironed out a performance regression, or the scheduler works better in this scenario, or filesystem access had issues with NTFS it could also cause performance differences in Linux favour.
Timberborn was worth buying when they came out in alpha, and have made so much progress since. Super fun game still undergoing frequent solid feature updates.
I've seen some optometry equipment running RHEL
I started using Linux maybe 5 years ago, just before DXVK and proton became a thing. The difference between now and then for gaming is night and day.
If it's on steam, there is a pretty good chance it'll work. If it's not on steam, it still might work through lutris.
There are some holdouts like Riot games, but I haven't owned windows in almost two years.
Hailey Williams. Wasn't even into that genre at the time, but her voice always made me think "wow, this is pretty good".
I work with SoC suppliers, including Qualcomm and can confirm; you need to sign an NDA to get a highly patched old orphaned kernel, often with drivers that are provided only as precompiled binaries, preventing you updating the kernel yourself.
If you want that source code, you need to also pay a lot of money yearly to be a Qualcomm partner and even then you still might not have access to the sources for all the binaries you use. Even when you do get the sources, don't expect them to be updated for new kernel compatibility; you've gotta do that yourself.
Many other manufacturers do this as well, but few are as bad. The environment is getting better, but it seems to be a feature that many large manufacturers feel they can live without.
It's a technology that lets you run code through the kernel's JIT compiler. It's an extremely flexible way to run code in kernel space; the typical example is using it to build XDP programs for networking, which can deeply analyse network packets without having to incur the performance penalty for changing context to userspace.
What kind of idiot workplace would allow that? Perhaps if you don't assume the people you talk to are literally brain-dead, you might understand what they're saying.
The GPU driver should already be in mesa, no?
It's distro-agnostic because Arch does very little to modify packages when they're put in the repos, which means they'll line up with the packages own man page & readme. The issue comes when opinionated distros modify things like command syntax, etc file locations and default behaviour.
If NixOS is similarly unopinionated, it'd only really have to document its own system layer, but my point is that Arch being guaranteed to reflect a well documented system is what drew me to it.
The code used in cve-rs is not that complicated, and it's not out of the realm of possibility that somebody would use lifetimes like this if they had just enough knowledge to be dangerous.
I'm as much a rust evangelist as the next guy, but part of having excellent guard rails is loudly pointing out subtle breakages that can cause hard to diagnose issues.
They most certainly are not. If you're buying unhealthy food only as snacks, you mistake your subset as all unhealthy food.
If you need calories and are on a shoestring budget, your options are potatos, bad bread, Coles cakes etc. You can eat for a week on a few dollars but you'll become overweight and eventually die of malnutrition. Your options become even more limited if you don't have a working stove due to being cut off your gas.
Aus border security care most about weapons and biological matter; dirt, wood, bugs, plants, food etc.
Coming from Indonesia, you may be profiled vis-a-vis potential biological material but showing that you've taken precautions when you packed to make their jobs easier will expedite any bag search.
Unrelated but have an off-site backup! Airport baggage handling are not gentle, and your spinning rust may be DoA.
Individualistic thinking such as "don't eat meat," or "don't have children," is making a moral judgement as well as using the trivial answer to the problem. (If there were no humans there would be no human-caused climate change, amazing.)
Saying "don't eat meat" is an individualistic proposal, but that doesn't mean it is ineffective or a moral argument; reducing the carbon intensity of the food you eat is undeniably effective at reducing the demand for carbon intensive foods. It's not the same as shutting down a factory farm, but it is still having an affect. It can't be the only thing done, but saying "that's an individualistic argument" seems like avoiding the fact that it is undeniably effective. Choosing to eat meat is an individualistic decision as well.
Not having children is more complicated. Humans don't inherently have a net positive carbon offset, because we are able to create things like carbon sinks that more than offset that person's individual carbon output. The problem is that our system as it stands actively discourages people from having a positive environmental effect. I choose not to have children, because in our current capitalist driven climate change train, having children is like bringing a log into a house fire; they're not going to make a big difference but they are kindling nonetheless and will suffer for it.
The advantages that we'll see come from the implementation more than the spec, but having an open standard for the ISA allows more companies to make implementations and to innovate.
The true benefits will be ~10 years in, when RISCV chip designers are more experienced and have had time to innovate and build good IP blocks.
E.g. companies that make ARM SoCs are pick'n mix'ing IP from ARM, and adding their own special sauce on top. The future in RISCV comes from having many companies that compete to make intercompatible IP, which hardware vendors like Qualcomm and Rockchip can then licence to make SoCs out of.
There is benefit to RISCV, over ARM but mostly that comes down to:
I've been considering copyfarleft licenses like the Anti-Captialist Licence and the Peer Production Licence for a while now; I like the licenses themselves, my only issue is that since there is no body like the FSF to enforce them, a company large enough is likely just to steal the code or break licence.
I don't see the problem, I also don't see how this is a novel situation.
The technical merits of system level protocols only really affect the user insofar as they make it easier for userspace application writers to make their software. This is why we have the distinction, so that users never have to change the underlying software, and when they choose to it's because everything just works.
Spyro the Dragon on PS1
Typically no, the top two PCIE x16 slots are normally directly to the CPU, though when both are plugged in they will drop down to both being x8 connectivity.
Any PCIE x4 or X1 are off the chipset, as well as some IO, and any third or fourth x16 slots.
So yes, motherboards typically do implement more IO connectivity than can be used simultaneously, though they will try to avoid disabling USB ports or dropping their speed since regular customers will not understand why.
It opens the door to more manufacturers since there is no ISA licence fees. While the AMD/Intel duopoly is being fairly competitive at the moment, it really doesn't have to be. Only think back to how bad it was late 2000s to 2015.
I imagine a plethora of core designers, soc vendors and platform creators filling their own niches; lowest cost, lowest power, HW accelerators, highest core count etc.
I don't see the raw performance of AMD/Intel being surpassed soon, just because of the sheer total R&D years each has, but that doesn't mean there aren't other areas better suited to a different architectural approach.
On an OrangePi with a powered USB hub using a bunch of SSDs.
All except the Minecraft server running on Podman.
Eggs are pushing $10/doz where I am 💀
You can absolutely put together a relatively healthy meal for reasonably cheap, I'm talking about "getting your gas cut-off" budgeting though.
Yeah in the short term there are going to be a lot of lose/lose scenarios for them, but this is the stupid prize for playing stupid games with what they released.
I hope they stock it out, games like No Man's Sky show both that a developer who cares enough to try can earn back the trust of a player base, and that the process to do so requires a lot of work.
Owning pirated materials is likely illegal in Australia, but it's not what border security are looking for so you're right they wouldn't care.
I'm surprised, and really pleased; I was under the impression that Nix required Systemd, and was thus a Linux exclusive. Good to see
I had an EdgeRouter X for years before I started my job. They are solid devices, and I'd definitely put them above most consumer routers.
Because they only charge for the hardware, they will eventually run into the same disincentive to provide consistent timely updates. If you do buy an Ubiquiti or similar enthusiast brand, do still keep an eye out for the CVEs that don't get patched.
My issue is not with the ARC, it's a few things:
kernel integration is iffy; I don't want to attach a module to my system every time I compile the kernel and prey that the difference in pace between the release schedules of openZFS and Linux hasn't caused issues, and because of the licencing issues my options of having a distro with zfs built in are very limited.
it's performance isn't excellent from a NVME standpoint. It's not terrible, but it could be better.
it has a massive code base, making introducing things like performance improvements and new features quite a challenge (Though the openZFS team are doing a bang-up job despite this).
Ultimately if I was still holding on to 40+TB of important data, I'd be using ZFS and be happy about it. I want snapshots on my workstation, without all the strange issues I've had with btrfs. I'm sure bcachefs will have its own issues but it's better to have options.
NixOS needs what is IMO the killer feature of Arch: the wiki.
Comprehensive documentation on not only the OS but the additional packages that we use is what drew me to Arch, and the thing that makes me swear in frustration whenever I have to use Ubuntu/Debian.
NixOS is an excellent OS that has the promise of being every bit as hackable as Arch, but far more stable. Problem is, configuration is very different and needs extensive documentation to reduce that friction point.