One could cope that this regulation can not apply to Linux or other OSS operating systems. But this is only true unless the bootloaders on consumer devices are mandated to be closed next.
We already have Secure Boot, the infrastructure is in place. It is currently optional, but a law like this can change that.
> (c) “Application” means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.
This is basically any program.
> (e) (1) “Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application.
This would include any package manager like dnf/apt/pacman/etc. They facilitate download of applications from third parties.
> (g) “Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.
This sounds to me like it would include distro maintainers. They develop and/or control the OS. Also, would this include the kernel devs? How would they be responsible for the myriad of package managers.
The overall law reeks of politicians not knowing what they're legislating.
Tokens are actually a very good RTS resource. If you allocate a fixed amount of tokens per map, a side with more of them would be able to spawn more agent units, or a few smarter hero units (with /think).
"Here's what we're going to do. We're going to accept the offer."
".. Gavin, Chrome is our primary ad ingest platform. We just used it to kill adblockers. Why, exactly, would we sell it?"
"I understand your concern, I really do.
But we must not let ourselves be constrained by the limits of our profitability!
Consider a gorilla.
The board members look at the conference room doors in panic, but nothing happens
A magnificent remote cousin that all of us share, particularly you, Devone. A gorilla is a peaceful, pastoral creature. But, if you were to strike your chest in front of it, it'll rip your head off and stick so far up your ass you choke on it.
breathes heavily
The gorilla, ladies and gentlemen, is the American justice system. And nothing, nothing, provokes it more than buying stuff with no intention of paying for it.
We accept the bid and Perplexity, obviously, fails raising 35 billion. Then we file a complaint, keep Chrome, get the popcorn and let the gorilla of justice explain to the competition the finer points of contractual law.
Ladies and gentlemen. This was Gavin Belson.
bows
"
---
Three weeks later, on Bloomberg news
"And with me is Mr. Bildt, a representative of a coalition of activist investors that raised 35 billion dollars for the Perplexity purchase of Google Chrome. Mister Bildt, what prompted you to assist what many consider to be a disastrous and unlikely deal? Do you expect Perplexity to manage Chrome better than Google?"
"God no. Given Perplexity's track record, we expect them to run the browser into the ground in 3-4 months, a year tops. Chrome accounts for some 80% of web traffic today. With its effective monopoly gone, we expect to capitalize on what many of us call a Belson-less market"
I have been thinking about adding conductive traces a-la PCB to 3D prints in a DIY setting for a while. Obviously, conductive filaments exist - but they are not remotely in the same category as copper.
My initial hope was that doping PLA, PETG or some other material with a conductor and then applying strong variable magnetic field near the print head to force creation of conductive domains while the filament is amorphous and hot. This turned out to be not feasible, as O3 explained to me repeatedly, over hours of chats.
A simpler and surprisingly workable solution appears to be adding a second printing head loaded with tin. Tin is not as good as copper - but it's still leagues ahead of conductive filaments. To offset the poor conductivity you can use thin, but very broad traces.
A speculative approach would work like this:
1. Print PETG layers using a regular filament, but leave "baths" for tin traces. A bath should be an opening at least 2-3 millimeters tall, to account for the surface tension.
2. After N layers, fill the baths from the tin head. Tin melting point is near PETG, but it would cool rapidly and, hopefully, weld to the plastic.
This way you could probably integrate a pcb into a print.
I haven't tried that, but i recall people actually trying to print with tin - so that part is at least not a complete fantasy.
This, I think non-planar PCBs are an incredibly niche thing, and very rarely necessary. you can just run wires/connectors between multiple PCBs, it's no biggie if your prototype needs some manual assembly.
Fiber laser etching is the way to go, the required equipment is already below $2000, and the process is quite simple. Additionally manufacturing copper/aluminium is next to impossible at home, considering their melting points.
You could even use a pre-masked copper plate (which is less reflective than copper), so your PCB would come with a mask.
Typing this from Moscow, over OpenVPN. I have been around the country over the last year and am yet to experience protocol-level blocks (although there are credible reports this happened, just not in my experience). It seems like the current wave is about blocking popular providers. Folks with own server, like myself, are not a target so far.
I'd expect the government to cool down expansive internet censorship until the "elections" in March, since hitting the preapproved outcome figures will be harder this way.
How do Guix and Nix userbases and contributor resources compare?
I like Guix as a standalone package manager much much more. It has first-class support for single-file environment config, and it's in lisp! But a package manager system ultimately comes down to resources poured into maintaining and supporting packages, it's a bootstrap problem. It's clear that NixOS has substantial support. What about Guix?
I like Guix better in principle as well, but it should be clear that its principled stance on what software can be packaged means it's a nonstarter for many people.
Well, with more than 23K packages, it's fair to say that Guix can satisfy the needs of many people, too. A lot of programming languages are pretty well represented!
Not just 23K packages --- that's just what is in the main Guix channel. Nix has a whole bunch of packages that are created automatically, on the fly, such as most R packages. The Guix equivalent would be the humongous guix-cran channel, which provides automatically generated R packages.
So I think comparing the size of package collections is less interesting than checking whether your packages are included. Personally, I would have a very hard time with Nix because I need the quality control in Guix that gets me packages that have been built completely from source without depending on opaque upstream blobs (e.g. bundled jars, minified JavaScript, etc). Because of that I wouldn't be able to use Nix productively for bioinformatics, statistics, and things like pytorch in the same way as I use Guix.
Good point. It's telling that many Nix vs. Guix discussions focus on three topics: DSL, popularity, and non-free packages. Few people talk about package quality control even though it's rather crucial for day-to-day use.
I'm not at all living in the Guix world, so please forgive my ignorance here. (I actually kind of gave up on the dumpster fire that are native binaries and happily live in my JVM bubble these days) But based on your article, I think you can take things a bit further to their natural conclusion
The last step is dealing with CMake. You can actually produce correct/reproduceabile crossplatform, crossarchicture builds WITH diamond dependencies and all that jazz if you integrate with the Hunter dependency manager. I think it's the only way you can get to a point where you don't end up with redundant dependencies at different version numbers
I mean, I actually frankly don't see a clear line between CMake "build orchestration" tools and dependency managers like Guix. Ideally Guix would just take over the function of CMake entirely - but it's missing crucial pieces. I think fundamentally you have 90% of the pieces there. You've already specified the whole dependency tree and dealt with linking/paths. The last 10% is extracting what CMake calls the "toolchain file" - ie. the specification for how you what you build done (target OS, architecture, compiler, linker and compilation/linking flags).
Ultimately it feels like with a bit more abstraction GUIX could be a truly crossplatform build/package manager. One could imagine for instance passing it a -debug flag and having it propagate to all dependencies and build your whole world with symbols. Debugging would become "full stack". Or passing in another flag and building one huge static binary with all dependencies and then doing PGO on it. Building crossplatform would become a breeze. Introducing a new architecture would be simply a matter of specifying a new toolchain file
I spent way too much time on reproduceabile CMake builds. We had our library reprucibly building for a huge amount of targets from Windows to iPhone 9 with a dozen dependencies that had diamond dependencies and it all worked beautifully. But I was kind of horrified that almost nobody in the C/C++ world really care about this. The tools were there and no one was using them (granted Hunter, while easy to use, has a bit of learning curve)
Ultimately I think it's something that needs to be solved at a "higher level" of the package manager bc cross language monsters like PyTorch are the norm now a days
This. NixOS was very usable for me back when Nixpkgs was the same size as Guix's package collection is now.
Additionally, Guix's package collection growth currently looks exponential, year over year. The package collection size gap, assuming it sticks around at all, is only going to shrink (relative to the total size of either collection) and matter less and less over time.
Guix can be extended with channels, and so there are channels like nonguix (for nonfree software) or guix-science (for software that's too messy to include in Guix proper) that go beyond what quality control keeps out of Guix proper.
> its principled stance on what software can be packaged means it's a nonstarter for many people
Including me. Guix actively makes it harder to install nonfree software, and that's against my personal principles, in addition to making my life harder on a practical level.
Guix actually makes an effort to make extensions of the maintained Guix channel as easy as the design choices allow. You can extend Guix in various ways: adding whatever channels you find or maintain yourself, extending it by setting GUIX_PACKAGE_PATH to a bunch of files, or by telling Guile to load some modules from somewhere else with "-L /where/your/files/are".
Guix doesn't care what software you install with it. It doesn't demand that you subscribe to any philosophy. The project just chooses to only package and distribute free software in the main channel. There are projects that have dedicated themselves to extending Guix with non-free or ... weird software. Guix will never go out of its way to make using those channels harder.
But if you dare to use the non-free channel, you get shouted at if you try to ask for any form of assistance, even for problems entirely unrelated to it. Speaking from experience.
wat? I'm using channels providing nonfree software. Even "worse", I contribute to those channels.
These channels are not for #guix, because the discussion there is meant for the base channel provided and maintained by the Guix project; but on #nonguix, or #guix-hpc (for e.g. guix-science, guix-science-nonfree, etc) you get to discuss these channels all you want and get help.
Using nonfree packages in Nix feels like buying wine at the grocery store: small, infrequent, ephemeral hassles. Using nonfree packages in Guix feels like having to go to a small, obscure package store across town.
I very much prefer the Guix community because based on my personal experience, it is more friendly and helpful than the Nix community. The main help ressources are the help-guix mailing-list and the IRC channel.
The thing with the paid subscription is that the bastards still track you. Paying for the service does not exclude you from surveillance, it supposedly makes it less obtrusive. Ad-blocker is insufficient for anything close to anonymity, and so is everything else. But it does make the tracking harder and it does move you ever so slightly to the tail of every distribution that matters for fingerprinting.
While this can be true, I'd be careful before making any inferences here.
For example, there's good research [1] on how FSB uses the fact that Telegram metadata is in the open to run counter-insurgency on occupied territories. This is likely among FSB's highest priorities - but there's no evidence that they have used some level of insider access or control (or at least that they are willing to burn it even on Ukraine).
Second, Telegram not being blocked is hardly an argument. Neither are Signal, WhatsApp or YouTube for example. Are all of these also controlled by the FSB? And the general embrace of z-propagandists is likely due the fact that Telegram is extremely popular all over post-Soviet space. As far as I know, pro-Ukrainian people use Telegram just as much, and just as much as a news source.
None of this is to say that Telegram is a good choice for a reasonably secure messenger or is trustworthy at all (and [1] lists some very convincing reasons for why it is not so). But "may be run by the feds" is a strong claim, and so far it is not supported by evidence.
Off topic, but is there a way to import existing mechanical designs like we do it in software with libraries? Something like importing a transmission design into CAD and gluing it to the model with API-like slots.
I'm very new to CADs and only have limited experience with FreeCAD, but having to design a latch anew every time you need it seems like a common enough pain point.
This is, in practice, the utility of the widespread use of CAD. Many manufacturers of parts distribute CAD models of those parts.
For example, McMaster-Carr have CAD models (in various formats) for nearly every single part in their catalog.
A designer/engineer can import those parts and then either create drawings referenced off of those parts, or mate/join those part using reference geometry. That is to say, the API is the geometry, and the CAD software provides good tools for interacting wit that API.
MCM's 3D parts are also great starting points for stuff you'd like to print for prototyping. I just printed off a bespoke belt pulley using an MCM model as a base this past week. Added a bunch of specific mounting features I need for my application. It's an inferior part printed in FFF, but it'll work for now.
I think for standard formats you start with STEP encoding and then there are various ISO semantic specs that encode to this, eg IFC for buildings (a standard BIM data format)
So i don't think STEP handles this explicitly, and while IFC does via URL-comptible file imports, it's rarely used in the wild.
Proprietary vendors use the standard formats for import/export but typically have poor support/wrong incentives for good interop.
There is interest in it tho, and I've talked with the OSARCH folks about it for BIM, and we're planning to work on it this year for bldrs.ai (open-source, links there to our discord and a #cad channel).
Ideally you import parts at the file level and have a compile step, like with code, where you load on lots of automatic integration tests
We're actually in process of building this for individual components (bolts, motors, gears, etc.) at: https://beta.govolition.com where you can search for components, filter by spec, download CAD/specs, and purchase the parts.
Onshape allows for versioning parts and assemblies, mate connectors to determine how parts should connect, assemblies and subassemblies to define the relationships between parts and allow for reuse, configurable parts (feature flags etc); it's extremely powerful and pleasant to use. Regrettably it's a closed source SaaS option but all of the open source CAD tools are grossly underpowered in comparison. There's nothing like KiCAD that'll let you get work done quickly effectively - at least in my experience.
The kernel (Parasolid) is closed source as well as many of the back end bits of Onshape, but all the code behind the standard features that is written in FeatureScript is under an MIT license (the Onshape Standard Library).
We already have Secure Boot, the infrastructure is in place. It is currently optional, but a law like this can change that.
reply