Commercial surveillance enables government surveillance. If an app constantly sends my location to a corporation by default, a government-level adversary can just demand it from that corporation, no need to burn a 0-day on me.
This is a complex thing. Don't give your location to the app. Turn off GPS, use VPN and don't use any apps/sites that linked with your real identity on the same device. Most of the other parameters in the commercial surveillance are too common to ID someone with a good probability.
Exploits, on other hand, can leak your full environment, including a photo from the cam.
Are you reading the same news the rest of us are? Companies are basically never found liable for a "hack" into their systems. And when the companies share user data intentionally, at worst they get a fine so low as to be meaningless. And in the US, usually not even that, because selling user data is mostly legal.
What usually happens in cases of government agencies getting hacked (in my non-US experience) is that an inspector investigates what went wrong, proposes improvements to security systems and processes, then monitors the agency to make sure they carry them out.
We wouldn't have to worry about over-the-wire package size if the modern DevOps approach wasn't "nuke everything, download from the Internet" every build.
Back in my Java days, most even small-time dev shops had a local Maven registry that would pass through and cache the big ones. A CI job, even if the "container" was nuked before each build, would create maybe a few kilobytes of Internet traffic, possibly none at all.
Now your average CI job spins up a fresh VM or container, pulls a Docker base image, apt installs a bunch of system dependencies, pip/npm/... installs a bunch of project dependencies, packages things up and pushes the image to the Docker registry. No Docker layer caching because it's fresh VM, no package manager caching because it's a fresh container, no object caching because...you get the idea....
Even if we accept that the benefits of the "clean slate every time" approach outweigh the gross inefficiency, why aren't we at least doing basic HTTP caching? I guess ingress is cheap and the egress on the other side is "someone else's money".
After reading the article, this comment and the comment thread further down on pnpm[1], it feels to me like the NPM team are doing everyone a disservice by ignoring the inefficiencies in the packaging system. It may not be deliberate or malicious but they could easily have provided better solutions than the one proposed in the article which, in my opinion is a band-aid solution at best. The real fix would be to implement what you mention here: local registry and caching, and/or symlinking a la pnpm.
Lots of places use a cache like Artifactory so they don't get slammed with costs, and are resilient to network outages and dependency builds vanishing.
From a few minutes of clicking around, most of these "office chairs" look entirely unsuitable for longer periods of work. I've also never seen a hotel room without at least a basic "school chair" and those are far more comfortable than a lot of the plastic slab or designer clamshell things I see in these photos.
I can't imagine the printers being open source or not mattering for that, nor can I see any reasonable government banning printing of specific things. If something is illegal to own or manufacture, that already applies to 3D printers just as much as it did to CNC machines or any other method.
Not quite the same, and hopefully likely to fail if it hasn't already, but it shows that interest exists in regulating 3D printers. When enough interest exists, things will happen.
Because violent criminals tend to lack wealth, knowledge, and skills. Nobody in the hood about to knock off a 7-11 has a tormach at home and the gcode for a reciever queued up.
I was very against Bambu in the beginning for their lack of proper network (not cloud!) support. Then they added LAN mode and I actually considered getting one. Luckily I was lazy and never got around to it. What the fuck Bambu?? Security, really? Not even HP dares to make that excuse...
Bambu Lab have been quite explicit about this. Their consumer-grade printers rely on a cloud service; for people who want or need printing over a private LAN, they offer the X1E.
That hasn't been true for years, the regular X1C has an officially supported lan mode and works fine without any of the cloud stuff. (I believe the smaller ones do too, but I haven't used them so I can't speak to them).
All HP printers still give you the option of paying full price for ink cartridges and owning the printer. The rental model is one they try very hard to steer you into, with lots of dark patterns, but you can still use HP printers with no account and no subscription ink model.
I mean, I technically see why authentication may be something they want to consider, especially for the less technically inclined users that Bambu is very obviously targeting.
However, this can be easily achieved without bricking every single third party integration. That should simple be a toggle in the settings that works entirely local
It's a shame "federation" these days basically just means "implement activitpub". So many projects get caught up in the complicated mess of mapping their data model onto AP, debating about how exactly to map things and writing standard extension proposals....
Useful federation between Forgejo instances could be solved with little more than OIDC and a few webhooks (cross-instance collaboration, forking, and PRs). Nobody needs federation between Forgejo and Mastodon - what would that even mean??
> So many projects get caught up in the complicated mess of mapping their data model onto AP, debating about how exactly to map things and writing standard extension proposals....
Well, you either use an existing standard so you can federate with existing implementations, or you come up with a new standard and ask others to implement that. Seems they chose the simpler way, thankfully.
> Useful federation between Forgejo instances could be solved with little more than OIDC and a few webhooks (cross-instance collaboration, forking, and PRs).
What about federation between more software than just your own? Once you've done those things, you basically end up with another spec (but informal instead of formal) that others also need to implement. So instead of going the informal way, they aim for the formal one. That does sound appropriate to me.
Slightly besides the point, but for someone who dealt more with decentralized/distributed systems than bloated authentication systems, it seems both simpler and easier to map+implement ActivityPub than implement OIDC+"a few webhooks", but that might just be because of my familiarity.
I'll say that ActivityPub is a pretty simple standard though, compared to what's out there.
When I saw “federated github”, sharing activity feeds is not what I had in mind. I thought maybe making pull requests across instances or things like that.
I tend to agree that ActivityPub seems pretty horrifying to work with (as an outsider). At least it works, though, and is implemented by a large amount of different projects and not owned by any single one.
> seems pretty horrifying to work with (as an outsider).
As someone who both made my own implementation + hacked on others, what was/seemed to be the horrible parts? It's a pretty simple standard that is basically RSS with some added stuff (very simplified of course, before I got jumped) for facilitating the federation parts.
> Useful federation between Forgejo instances could be solved with little more than OIDC and a few webhooks (cross-instance collaboration, forking, and PRs).
That would only solve the problem of "I don't have an account on this forge yet". The much more relevant problem is identity + reputation. With ActivityPub-based federation you can use your domain-bound identifier to contribute to various projects across servers and gain reputation and trust. If we use OIDC, then it is a lot less clear if the server, you authenticate with, is hosting the real franga2000.
So let me get this straight - you want to go from a system where:
- the government hands out money to the media
- the law says that they need to give it to everyone without political discrimination
- if they try to withold funding, you can sue them and probably win
To a system where:
- if you have a ton of money, you can be a media outlet
- if you don't have a ton of money, get fucked
I'm struggling to see how the latter is better for anyone other than rich people who want to influence the masses.
In theory your argument could be good, in practice the state is governed by the same horrible people that run corporations, and at least with corporations they topple over every 25 years.
So yes I’d prefer not to let leeches take my money by force to give it to media, worst of all to tell the things they said against whites during the last 4 years. I mean, the proof that they’re bad is exactly what you paid them to say recently.
Where do you buy such things? Every USB Ethernet card I've used in the last 10 years was either RNDIS or some version of USB-CDC. They've worked out of the box on both Linux, Windows and some even Android.
If you start the configuration of the Linux kernel and you go to "Device Drivers", then to "USB Network Adapters", you will notice that there are close to 50 such device drivers.
That should tell you that there are plenty of different USB Ethernet Adapters that you can find when buying one.
Among those that I have encountered more frequently have been several kinds of Realtek, and of ASIX, and of Aquantia.
Especially among the faster USB Ethernet adapters I doubt that there are many without custom drivers.
Some people may not notice this, if they are using only fat Linux kernels, with all the possible device drivers being enabled and compiled, but if you use a streamlined kernel, e.g. for instant booting, you may need to add a device driver whenever you buy such an Ethernet adapter.
reply