I don’t believe that only 800 people played on Linux. It makes no sense to me in the grand scheme of things. I have a personal YT channel with only 108 subs and my random low effort video on how to get League running on Steam Deck has almost 70k views which is nuts and there are many other much better videos than mine with many more views. If only 0.1% of those people are active players that would still make a lot more than “800” figure. I know this is just a random speculation but 800 is just waaaay too low.
While walking past an office I got called in, the headmaster’s secretary and the music teacher were struggling and told me the flash drive they had does not work.
So I take a look and pull the flash drive out of the Ethernet port and plugged it into a USB port and told them they need to plug it into the correct port.
The look on their faces.
But then I admitted to them that I had never seen this happen before and that I didn’t know that the Ethernet port was the right width to take a flash drive.
I mentioned this can be done on a Discord server I am on and nobody would believe me so I just told them to give it a try. They probably think I was trolling to this day.
Far left is no landlords really. Like maybe small scale for like older people who prefer not to own condos and do any maintenance in elderly years, or students or people temporarily in another country or something, but no massive bloated greedy parasites like now.
How would apartments work, ideally? I guess have a contract where everyone living in the apartments owns a percentage of the building, and therefore the community of people that live there are responsible for building maintenance and other stuff like that, right?
I feel like this is easy to answer and I’m not sure why the question comes up so often.
People have jobs and get payed salaries to both build and maintain houses/apartments. Rent payments would go to pay the actual people that did the building / do the maintenance. Nobody makes profit off this. No landlord, no investor, no profit. The money goes to cover building costs, then maintenance. Easy peasy.
We have things like this. People build and maintain our public roads, schools, water/sewer systems, fire departments, military, etc.
No profits. No landlord gets free money for renting. No wallstreet investor gets free money for selling at high market values, etc.
Obviously, decisions have to be made about supply/demand, areas where lots of people want to live and all that. So what? Let’s make those decisions intelligently instead of greed and profit driven.
You just described a housing cooperative. This form of collective ownership aligns owner and renter/home owner stakeholders as the same person and is a special form of consumer cooperative. Housing cooperatives are especially prevalent in the nordic countries. They keep prices down as they aren’t owned by shareholders who want continuous profit. The problem with this style of firm is that they tend to dissolve after the tenets collectively pay off the property and seek to sell rather than maintain or expand the cöop. This occured after world war 2 in France as a bunch of post war building were quickly built and the coops that built them were dissolved.
Isn’t that how most apartments work? The apartment I live in, and every apartment I know of has an “owners corporation”, of which each owner of each apartment is a member. The members have meetings and elect a committee to make financial decisions. All members pay fees to the owners corporation. Most of the money goes to a building manager, which is an external company hired by the owners corporation to maintain the building. The building manager handles repairs and cleaning of the common areas and facilities. Any non-routine spending must be approved by the committee (and large expenditures, such as elevator replacement, would go to a vote of all members).
…
Anyway, the gist is what you said. Individuals and families own the apartments, and collectively they own the whole building and make decisions about how it should be maintained and run.
I don’t think you can simply call state housing authoritarian or housing coops Anarchist, political science isn’t really binary, nor even grid-based like the political compass wants it to be.
I’m absolutely new to Linux (thanks to steam deck, which I think is arch Linux), what is KDE 6? Is that like a new OS update? Are there any implications for steam deck users?
Thank you for making such a thoughtful response! Out of curiosity, does this mean KDE actually runs on other distros of Linux as well? Until now, I had been under the impression that KDE was just arch Linux itself.
Would you happen to know a good way for me to learn more about Linux, and how to put it to good use from a beginner’s perspective?
Followup on the other person’s response - I don’t actually know of any modern desktop distro that doesn’t support KDE. That’s not because distros go out of their way to package KDE, but simply because at the end of the day, KDE is simply a fullscreen app (with a heck of a lot of functionality), and if you can compile code, you can compile and run KDE.
If you like youtube, the linux cast is a great option. For news though, the linux experiment can’t be beat. You’ll learn more as you go along and always know you can ask questions if you have them
Thanks! I just watched a video the Linux cast posted about KDE, and found a KDE 6 video posted by the Linux experiment. I’ll watch that one later. There’s still a lot of terminology that is lost on me, but I’m sure I’ll pick it up in time.
The new terminology will be never ending. The unix philosophy is to make small tools that do one thing really well (vs a single large monolithic OS that does a ton of things half decently), so every single component in and around Linux has a name, its own set of maintainers, and pages of documentation you could spend hours to months learning (depending on the tool).
On top of that, the open source ecosystem isn’t centralized, there’s no CEO telling everyone the one way to do things. Instead, everyone is free to build whatever they want according to whatever design patterns they choose. This is a blessing and a curse. There are packages that work nicely with other packages, and there are many you probably shouldn’t waste your time with.
All this is to say, I recommend always having a goal in mind when digging into Linux, and get good at skimming new terminology that you think is relevant to your goal. Be able to quickly understand what something does and how it’s used, but avoid going down the rabbit hole for every little thing.
That’s not to say you shouldn’t satisfy your curiosity, just know that you can be overwhelmed quickly if you don’t know how to tune out the noise. Being goal oriented helps me stay on task as I learn.
If you’re interested in KDE in particular, you should also check out Nicco Loves Linux. He’s one of the KDE developers and makes a lot of videos about it.
to answer your question KDE is not arch. Linux has a bunch of distros, you can think of one as a collection of packages. some distros want to do things one way some want to do it others.
the biggest difference between distros for most users are mostly desktop environments and package managers. KDE is the desktop enrollment, there are many others that you could also use, like gnome, or use none at all and only use the terminal. the package manager is how you get new packages and update the ones you already have. examples are apt and pacman.
you can make any distro work like another by installing the same packages, although this may not always be the easiest to do. an easy way to change your experience with Linux is to try a different desktop environment, you can run multiple on the same distro and switch between them, see what you like.
Until now, I had been under the impression that KDE was just arch Linux itself.
Like others have already noted, KDE Plasma^[1]^ is widely available and thus not only limited to Arch Linux. Heck, the same applies to 99% of the available software on Linux; universal package managers^[2]^ have been vital to this.
Would you happen to know a good way for me to learn more about Linux, and how to put it to good use from a beginner’s perspective?
As you already own a Steam Deck, I assume you want to look into how you may improve your mileage out of it. Others have already noted how you may do so for more traditional systems. But the way Linux is utilized on the Steam Deck is rather unique. It utilizes immutability^[3]^ (i.e. the inability to make certain (permanent) changes) which makes it rather harsh to change certain parts of the system; SteamOS’ implementation might even require you to redo some of these changes every so often… which is probably not what you were expecting. To circumvent this, perhaps it’s worth exploring other SteamOS-like distributions that are more friendly towards tinkerers. There are many to choose from; perhaps this breakdown may help you with making an informed decision (even if it’s found on a page dedicated to the Legion Go).
That is, the desktop environment (i.e. the piece of software responsible for how you visually interact with your system) that team KDE works on. They’re also responsible for many other projects; like Kate, Kdenlive and Krita etc (these are often easily recognized by their names that start with a “K”).
We may refer to package managers as the original App/Play Stores; a piece of software used to find, install and upgrade software. For a long time, every major distribution (like Arch, Debian and Fedora) had its own repository (i.e. set of installable software through the package manager). This meant that, it was very conceivable that software may be packaged (i.e. distributed and maintained through the repository) on some distros (abbreviation for distributions) but not on others. In the last couple of years, so-called universal package managers (like AppImage, Distrobox (technically this doesn’t belong here, but it does allow access to packages found on (other) distros), Flatpak, Guix, Nix and Snap) have become alternative package managers that are distro-agnostic. And have slowly, but surely, ridden Linux distros from concerns related to package availability.
There’s a lot to say about immutability. But for now, it’s most important to note that not all systems that are (sometimes falsely) referred to as immutable are created equally. For example, the respective implementations for Bazzite, Jovian NixOS and SteamOS differ immensely from one another. Arguably, referring to Bazzite and Jovian NixOS as immutable with ‘unchanging’ being what’s implied, would be a major disservice to both projects.
As a senior at my last big company job, basically all I did was conduct meetings and do PRs. It’s such a grind.
My opinion now is that most PR is worthless anyway. Most people give, at best, a superficial skim for typos, lack of comments, or other low-hanging replies (that usually, really, a static checker or linter should be dealing with).
Reading the code base in little chunks like that doesn’t give you proper context for the changes you’re reading. Automated unit and integration tests would be better for catching issues like that, but of course then who is reviewing and verifying the tests? Who’s writing them for that matter?
Ideally, pair-programming or having extra people on projects to create knowledge redundancy would help. But companies want to replace juniors with AI now, so that’s not looking good. Senior devs and architects might know the major pieces of much of the code, but can they “load it into working memory” sufficiently to do a quality PR that will catch something the tests didn’t and QA wouldn’t? Not in my experience.
I think the best actually-implementable solution for most teams is to get rid of PR expectations and take a multi-pronged approach to replacing that process.
use tooling to check for and fix basic stuff. Use a linter, adopt a code standard, get a code formatting tool that forced adherence to the standard and run it on every PR.
Unit tests if you got them, start if you don’t. You don’t need 90% code coverage, just make sure critical paths are covered.
Turn one of your useless meetings into a code review session. Each week/sprint, one Very Important Code section is presented by the developer that works on it most or that last changed it. This helps the whole team learn the code base, gets more eyes on the important stuff regularly, and enforces not just a consistent style but a consistent approach to solving and documenting problems.
PR (and the github PR approval stuff or its equivalent for you) should be streamlined but preserved. Do have a second person approve changes before merging, just to double check that tests have finished and passed and all that. If your team is so busy that no one ever approves PRs then allow self-approval and be done with it. This will make regular code review very important for security and stability, since any dev could be misbehaving unseen, but these are the trade-offs you make when burning out your team is more important than quality.
I caught a junior trying to reimplement an existing feature, poorly, in a way that would have affected every other consumer of the software I’m a code owner on a week or two ago. There’s good reason to keep them around.
PRs suck to do, but having a rotating team of owners helps, and linting + auto formatting helps with a lot of the ticky tacky stuff.
Honestly, the worst part is “newGuy has requested your review on a PR you requested changes on but he hasn’t addressed” that’ll get you in the ignored pile real quick.
I generally agree and like this strategy, but to add to the other comment about catching reimplemented code, there’s just some code quality reviewing that cannot be done by automating tooling right now.
Some scenarios come to mind:
code is written in a brittle fashion, especially with external data, where it’s difficult to unit test every type of input; generally you might catch improper assumptions about the data in the code
code reimplements a more battle tested functionality, or uses a library no longer maintained or is possibly unreliable
code that the test coverage unintentionally misses due to code being located outside of the test path
poor abstractions, shallow interfaces
It’s hard to catch these without understanding context, so I agree a code review meets are helpful and establishing domain owners. But I think you still need PR reviews to document these potential problems
these are the trade-offs you make when burning out your team is more important than quality.
Yep.
Many directors and CIOs know exactly where they stand regardingthe classic value proposition: deliver something trivial before next quarterly earnings statements - at the low easy cost of losing all organizational understanding of the code base.
The fun part is – it is superior because it includes missions you can do in coop unlike it’s release on PC where they were cut. I don’t remember if it could play your own music tho.
lemmy.ml
Top