just use a community-lead or non-profit foundation lead distro: NixOS (better than silverblue/kinoite in all aspects they try to sell), Arch, or Debian.
For professional usage, you generally go Ubuntu, or some RHEL derivative.
For the first time ever in space, scientists discovered a novel carbon molecule known as methyl cation (CH3+). This molecule is significant because it promotes the synthesis of more complex carbon-based compounds.
it’s simply too difficult for average person to login and apply to every single instance that they’re interested in
Maybe there are some misunderstanding, but why would one want to apply to multiple instances at the same time? Just applying and being active on 1 good instance isn't enough?
Totally supportive. Great to have a wayland Rust implementation (and Rust increasing adoption by FOSS community); more specifically, smithay, which further than System76 is building upon, like projects by the community this WM for example https://github.com/MagmaWM/MagmaWM
Well; darwin users, just as linux users, should also work on making packages available to their platforms as Nix is still in its adoption phase. There are many already. IIRC I, who never use MacOS, made some effort into making 1 or 2 packages (likely more) to build on darwin.
as Reddit now going to IPO. That happened to Twitter->Mastodon, can happen to Reddit->Lemmy as well.
We had seen it coming haha
I can keep Firefox bleeding edge without having to worry that the package manager is also going to update the base system, giving me a broken next boot if I run rolling releases.
On Nix[OS], one can use multiple base Nixpkgs versions for specific packages one wants. What I have is e.g. 2 flakes nixpkgs, and nixpkgs-update. The first includes most packages including base system that I do not want to update regularly, while the last is for packages that I want to update more regularly like Web browser (security reasons, etc).
e.g.
When I was packaging Flatpaks, the greatest downside is
No built in package manager
There is a repo with shared dependencies, but it is very few. So needs to package all the dependencies... So, I personally am not interested in packaging for flatpak other than in very rare occasions... Nix and Guix are definitely better solutions (except the isolation aspect, which is not a feature, you need to do it manually), and one can use at many distros; Nix even on MacOS!
Some of them will detect if using virtualization. For example http://safeexambrowser.org/ by ETH Zurich
Ironically enough, it is free software https://github.com/SafeExamBrowser
their work essentially go in the trash
They learned a lot in the process probably, that is the most important for them after all. But relying on API is risky, so always go HTML scrapping. The frontends are super useful for finding information already there without accessing the actual website. Always use Lemmy here for everything else.
cross-posted from !softwareengineering@group.lt: https://group.lt/post/46385
Adopting DevOps practices is nowadays a recurring task in the industry. DevOps is a set of practices intended to reduce the friction between the software development (Dev) and the IT operations (Ops), resulting in higher quality software and a shorter development lifecycle. Even though many resources are talking about DevOps practices, they are often inconsistent with each other on the best DevOps practices. Furthermore, they lack the needed detail and structure for beginners to the DevOps field to quickly understand them.
In order to tackle this issue, this paper proposes four foundational DevOps patterns: Version Control Everything, Continuous Integration, Deployment Automation, and Monitoring. The patterns are both detailed enough and structured to be easily reused by practitioners and flexible enough to accommodate different needs and quirks that might arise from their actual usage context. Furthermore, the patterns are tuned to the DevOps principle of Continuous Improvement by containing metrics so that practitioners can improve their pattern implementations.
The article does not describes but actually identified and included 2 other patterns in addition to the four above (so actually 6):
The paper is interesting for the following structure in describing the patterns:
- Name: An evocative name for the pattern.
- Context: Contains the context for the pattern providing a background for the problem.
- Problem: A question representing the problem that the pattern intends to solve.
- Forces: A list of forces that the solution must balance out.
- Solution: A detailed description of the solution for our pattern’s problem.
- Consequences: The implications, advantages and trade-offs caused by using the pattern.
- Related Patterns: Patterns which are connected somehow to the one being described.
- Metrics: A set of metrics to measure the effectiveness of the pattern’s solution implementation.
cross-posted from !softwareengineering@group.lt: https://group.lt/post/46385
Adopting DevOps practices is nowadays a recurring task in the industry. DevOps is a set of practices intended to reduce the friction between the software development (Dev) and the IT operations (Ops), resulting in higher quality software and a shorter development lifecycle. Even though many resources are talking about DevOps practices, they are often inconsistent with each other on the best DevOps practices. Furthermore, they lack the needed detail and structure for beginners to the DevOps field to quickly understand them.
In order to tackle this issue, this paper proposes four foundational DevOps patterns: Version Control Everything, Continuous Integration, Deployment Automation, and Monitoring. The patterns are both detailed enough and structured to be easily reused by practitioners and flexible enough to accommodate different needs and quirks that might arise from their actual usage context. Furthermore, the patterns are tuned to the DevOps principle of Continuous Improvement by containing metrics so that practitioners can improve their pattern implementations.
The article does not describes but actually identified and included 2 other patterns in addition to the four above (so actually 6):
The paper is interesting for the following structure in describing the patterns:
- Name: An evocative name for the pattern.
- Context: Contains the context for the pattern providing a background for the problem.
- Problem: A question representing the problem that the pattern intends to solve.
- Forces: A list of forces that the solution must balance out.
- Solution: A detailed description of the solution for our pattern’s problem.
- Consequences: The implications, advantages and trade-offs caused by using the pattern.
- Related Patterns: Patterns which are connected somehow to the one being described.
- Metrics: A set of metrics to measure the effectiveness of the pattern’s solution implementation.
cross-posted from: https://group.lt/post/46053
A group of astronomers poring over data from the James Webb Space Telescope (JWST) has glimpsed light from ionized helium in a distant galaxy, which could indicate the presence of the universe’s very first generation of stars.
These long-sought, inaptly named “Population III” stars would have been ginormous balls of hydrogen and helium sculpted from the universe’s primordial gas. Theorists started imagining these first fireballs in the 1970s, hypothesizing that, after short lifetimes, they exploded as supernovas, forging heavier elements and spewing them into the cosmos. That star stuff later gave rise to Population II stars more abundant in heavy elements, then even richer Population I stars like our sun, as well as planets, asteroids, comets and eventually life itself.
About 400,000 years after the Big Bang, electrons, protons and neutrons settled down enough to combine into hydrogen and helium atoms. As the temperature kept dropping, dark matter gradually clumped up, pulling the atoms with it. Inside the clumps, hydrogen and helium were squashed by gravity, condensing into enormous balls of gas until, once the balls were dense enough, nuclear fusion suddenly ignited in their centers. The first stars were born.
stars in our galaxy into types I and II in 1944. The former includes our sun and other metal-rich stars; the latter contains older stars made of lighter elements. The idea of Population III stars entered the literature decades later... Their heat or explosions could have reionized the universe
More information:
Yes. Merge both or redirect one to another. Seems atemu is not active here, but I think I have saw someone by that name in some nix official channel like matrix or discourse or nixpkgs repository. You could ask Lemmy admin as well
oh this is one of my wallpapers
i did a 1920x1080 version out of it by horizontally tiling 3 duplicates of it like this (i got the freely licensed version from wikimedia commons under https://creativecommons.org/licenses/by-sa/4.0/deed.en)