“almost all of the most technical employees in framework are using either ubuntu, fedora or nixos. I’m mostly on Windows because we need actually people that are using Windows because our employee base in framework is all Linux users”
My Linux journey started when Ubuntu was in its single digit versions. I don’t remember the exact version I used first, but it was >15 years ago.
Of course I had a long distro hopping phase, that got finally ended by Arch. Because Arch breaks less, at least if you don’t molest it. Upgrades of versioned distros always had hickups or problems, and I grew tired of having to do a larger troubleshoot session once or twice a year. Arch has only very minor hiccups once in a while, and they’re typically always the same. 99% when the update doesn’t run through the keyring changed and you have to update it first, .9% is a bug with like a new release of the DE or something that gets fixed upstream in a couple days. And .1% is you have to look at the news because some manual intervention is required, like removing a package and going for something else or whatever. That is when you keep your system free of cruft and go with a popular DE.
Just 1.5 years ago I finally left Arch after a loong time. For something that is very new and different: fedora atomic (silverblue). Technology wise it is superior in my mind, and in my last years of using Arch I had most things in Flatpaks and containers anyways. But if you want a classical distro, Arch is definitely amongst the very well working ones.
The more packages you install rpm-ostree, the likelier your system will break. You effectively turn back to a traditional distro that relies on a package manager, so all the things that can go wrong with a package manager are bound to go wrong. The whole point of fedora atomic is to offload the OS composition (so all the complicated packages stuff) higher up the chain. So that not everyone mixes up their own combination of packages installed, but instead you get a (semi-) fixed combination of packages that has been tested to work already before it lands on your computer.
The uBlue images are just different package combinations - but still you’re not the only one rocking the packages combination of bazzite for example, so it is rather unlikely you’ll run into a problem that only you and nobody else has.
This to me is also what sets fedora atomic apart from Suse MicroOS for example. With MicroOS you still have a package manager messing about with the system, and once it makes a mistake that gets buried in your system forever, except if you notice, roll back and fix it. As where with fedora atomic the mechanism how your system layout comes to your computer is similar to how git works (ostree) or images (like docker, which is what ublue ships). So if there’s a mistake in how your system is layed out, the next time you rebase/update you are guaranteed to end up with a the intended system layout.
Hm well, I caried a Yoga l390 in a Backpack for 3.5 years and opened+closed it many times a day. That thing is now 5 years old. It’s not being used daily anymore, but still multiple times a week. And it still works perfectly in every regard. Only the hinges became a bit less stiff and the battery capacity went down a bit. But those are a given with that age and amount of charge cycles.
Since 1.5 years I have the pleasure to work fulltime with a fully specced x1 Yoga, that also has to go into the backpack every day. Of course that’s not very old, but it also has zero problems, only the silver paint at the corners started to wear off slowly from carrying it around.
The stylus that stows in the case is annoyingly small (and you need a seperate normal sized one for extended writing), but other than that it has all been very positive for me.
Take a look at the Lenovo Yoga models. There are very well built thinkpads out there that fold over and have a stylus + touchscreen
There’s also CadQuery, which I find more intuitive to use than openscand: https://cadquery.readthedocs.io/en/latest/intro.html
The problem is not the EU demanding that, it rather is Apples blatant incompetence at implementing it
Nono, you are demanding in a not nice tone from a open source community to implement some bloat workaround to fix some you-specific-issue with commercial software. You know how free and open source software works? Either you contribute something positive, or you color yourself glad you get to use something so great completely for free and stay silent. Bark at that commercial vendor that doesn’t use the money from licenses + selling your soul to build something half decent! This upcoming demand-culture around things that others kindly share with wanting nothing in return pisses me off. Especially when it’s not even something about the project, but carrying over unrelated cruft, instead of directing the demand to the entitiy it would be justified against.
Just build a browser extension that does the conversion. Or a script that watches a folder where you drag it into as an intermediary, and then it converts it automatically. And then share it for free, because you are a kind person! You might find a handful of people that like it. And then watch some asshat writing you a demand that “stop converting to jpeg, forever stop that! I need bitmaps for my gameboy! Just give me a SETTING where I can chooose and a nice dialog where I can pick the freaking color palette!”
You using shitty software is not something somebody else would or should feel inclined to solve. Suggesting that everybody should suffer from not receiving the content they request from the webserver, but instead an arbitrary lossy compressed and therefore different picture for your individual comfort is just a self-centred, ignorant and narcissistic request. So go away and use edge, and then complain to Microsoft (whom you pay in contrast to mozilla+community!), that their shitware doesn’t work.
Research what happened to Upstart, Mir or Unity. It won’t take long until snap becomes one of them. Somebody at canonical seems to desperately obsess over having something unique, either as a way to justify canonicals existance or even in the hopes of making the next big thing. Over all these years they never learned that whatever they do exclusively will always fall short of any other joint efforts in the linux world, because they always lack the technical advances, ability/will to push it for a prolonged time and/or the non-proprietary-ness. So instead of collaborating like every serious linux vendor, they’re polluting their distro with half-assed, ever changing and unwanted experiments. They’re even hijacking apt commands to push their stupid snap stuff against the users intent. With the shengians they’re pulling Ubuntu cannot be relied on, and with that they’re sabotaging their own success and drive away any commercial customers that generate revenue.
Also I think nobody so far weighed the energy consumption of e.g. using copilot against the environmental footprint of a human doing the legwork manually
Specifically the shitty IPU6 situation is on Intel, and is invariant to any laptop manufacturers. I also have a Thinkpad X1 with that issue. So for that the situation that one manufacturer would support it properly (i.e. upstream) and others don’t can’t exist, as soon as anybody puts it upstream it works for everybody. Thankfully there’s some progress (search for libcamera) and in the not too distant future it should work ootb. For fingerprint readers it is a different story though, as there are many different ones, so that one is on Dell indeed
One possibility would be Huginn I guess https://github.com/huginn/huginn
You have this view because your hardware is from an era where fingerprint reader largely weren’t a thing and webcams were connected via internal usb. The issue is not that the Linux kernel drops anything (between you and op, you’re the one with the old hardware). The issue is, that fingerprint readers became a commodity without ever gaining universal driver support, and shengians like Intel pushing its stupid IPU6 webcam stuff without paving the way upstream beforehand
Well you must have either set up a port redirect (ipv4) or opened the port for external traffic (ipv6) yourself. It is not reachable by default as home routers put a NAT between the internet and your devices, or in the case of ipv6 they block any requests. So (unless you have a very exotic and unsafe router) just uhhh don’t 😅 To serve websites it is enough to open 443 for https, and possibly 80 for http if you want to serve an automatic redirect to https.
That’s odd, I upgraded my ender 3 with bed leveling and removed the knobs to mount it fixed, because the damn knobs keep moving and then you have to redo the bed calibration. To be honest I can imagine one reason might be that a loosely mounted bed gives you more fault tolerance against the nozzle being too low. I put my bed on two parallel linear rollers for more rigidity, and combined with dual z screws the nozzle has no chance anymore to produce any sort of first layer when it is slightly too low. That made me realize just how much the stock ender 3 is flopping around, but also how this can give you mostly okayish results most of the time without having to deal with a ton of small tolerances.
A colleague of mine had a (non externally reachable) raspberry pi with default credentials being hijacked for a botnet by a infected windows computer in the home network. I guess you’ll always have people come over with their devices you do not know the security condition of. So I’ve started to consider the home network insecure too, and one of the things I want to set up is an internal ssh honeypot with notifications, so that I get informed about devices trying to hijack others. So for this purpose that tool seems a possibilty, hopefully it is possible to set up some monitoring and notification via uptime kuma.
Well it is compiled to byte code in a first step, and this byte code then gets processed by the interpreter. Now Java does the exact same thing: gets compiled to byte code which then gets executed by the jvm (java virtual machine), which is essentially a interpreter that is just a little simpler than the python one (has fewer types for example). And yet, nobody talks about a java interpreter
You do not want Octoprint on a machine that is busy. Otherwise you have load spikes that cause Octoprint to not be able to send the move-commands (gcode) as fast as the printer executes the movements. This problem is pronounced with faster printers and slicers that break up arcs into small straight lines (which is practically all slicers). Otherwise your printer stutters because it has to take small breaks to wait for the next command from octoprint.
That power efficiency is a direct result of the instructions. Namely smaller chips due to the reduced instructions set, in contrast to x86’s (legacy bearing) complex instruction set.