Oh no, portable workstations are a whole nother thing. This was 100% marketed and sold as a laptop. But gaming laptops have never been good with battery life.
They even tried to make it thin and light, which makes me cringe every time. Gamers don't need thin and light, wtf.
You would not be correct. If
It has to influence something. Being chairman of the board is much less prestigious or important than CEO or president which is actually doing work. Chairman of a board is a figurehead position.
You can paper launch as much as you want but Blackwell isn't shipping until Q4.
Also Blackwell's lead will be short lived, because mi350x is coming out next year, and it will have a node and architecture advantage. So AMD will be ahead again.
Way-not-gonna-land as someone said some years ago. :-P
I'm using Wayland for my work now for two years now, and it has been amazing.
But then, I rarely do any graphics work.
The stuff that gets your desktop started up into a usable state. Same as on any OS, macOS or Windows. The software that is expected to be there on a given version of the OS, that other software may depend on being at some particular (major, at least) version until there’s a new version of the OS.
The stuff that updates when you update the OS.
On macOS, the software that’s not an optional package manageable through the App Store (even if installed by default) or managed by Homebrew or what have you.
This is a distinction that should NOT exist. Like on phones, you end up with "software" that is just a glorified web browser and doesn't integrate with the rest of your system nor cannot access your hardware to its full extent.
I.e. If I want to set up a script that makes Libreoffice trigger phone calls through a bluetooth modem, I should be able to. Otherwise it isn't really a computer. These "system" vs "non-system" almost always end up down this slippery slipe, and avoiding it is one of the reasons I enjoy desktop Linux for all its brokenness.
It’s very nice when it exists because you can do whatever you need with user-facing software without risking system stability. Long-term stable versions of basic software, including gui libs, also provides a reliable target for software deployment.
I've made up half a dozen definitions for it before asking, and none of them were a good guide to decide about the software on my machine. Yours seems to focus on the DE components, what is both way too restrictive (why are `ls` or `test` out?) and way too inclusive (my DE installs with an Earth rendering and graphic calculator, my workplace's DE installs with CandyCrush).
A universal definition isn’t needed to apply the concept, in the same way the Internet can’t agree on some fixed universal definition for what a sandwich is, yet this doesn’t impair assembling a BLT.
It is in fact applied by organizations, and they manage fine, so lack of a universal definition isn’t a hindrance.
If you want to guarantee certain versions of ls or test are available for the duration of the supported life of an OS, yeah, they’re part of the base system. This kind of arrangement is very nice for both users and software vendors. The base-system instability of an Arch or a Gentoo (rolling release), or the ancient productivity-software packages of a Debian, aren’t the only options—lockstep-release stable base system and rolling release user packages are an option.
You say 1 and 7 are project goals but I don't agree and I'll say why:
1. If you are not keeping your project alive and it is useful, then someone else will take your project and keep it more alive. and your influence will reduce. So, assuming that you are a good BDFL, you should make effort that your project is alive so that the BDFL at top is good.
2. The ability to fund people for the project is as much a story of actual resources as it is about the culture. If you do not try funding people right from the start, you will accumulate people are also not that interested in funding people. This means your project will remain a hobbyist project. And this actually impacts 1 because then your project might not be that sustainable.
ok, so point 1 is about making sure i don't accidentally lose control of the project. i am not sure that matters. if my life dictates that i focus on other things then this is a natural development. for me the guiding principles should dictate my behavior but not my priorities. (unless it comes to priorities within the project when they affect the community). saying that i have to stay on top of the project is claiming that i am the only one capable of leading the project. that may or may not be true.
it also may or may not be important for me to keep being the leader of the project. there was at least one project that i started that i was eventually no longer using and i happily passed it on to someone else.
if anything, as a behavior rule i'd add: step down when the project is no longer important to me.
on point 2, i am not sure. most project founders have the problem to get even themselves funded. far from being able to fund others. and i disagree that not funding people from the start means it will remain a hobby project. just look at debian. it got huge without paying people to work on it, and infact attempts to introduce paying people caused a number of high level contributors to get upset and leave the project.
so yes, funding does affect what kind of people are attracted to the project, but, funding others from the start is unrealistic. and the people i pay to work on my project are people who will leave the moment i stop paying them. they see it as a job and i see them as employees or contractors (and that is not hypothetical, i am in fact paying someone right now to help me on a foss project, and i get paid from that project too (so i am a contractor with a subcontractor)). before i got paid i was an inactive member of that community, and when i stop getting paid i will probably become inactive again because i can't afford to spend a lot of time to contribute while i have to work other contracts.
so i am not sure there is a benefit to the community to have these people around. participation in a community tends to be voluntary. and communities either function well when everyone gets paid in some form, or noone. paying some people and not others is asking for trouble, unless the project is a commercial entity that needs paid workers to serve paid customers. but then again, the paid workers and the company itself are not considered part of the community, but instead they are the owners of the community. that's a different relationship.
> so point 1 is about making sure i don't accidentally lose control of the project
Not my intent at all. It's about signalling to existing users, prospective users, existing developers and prospective developers that the project is alive and kicking.
Why do they need to be "maintained"? Assuming they're set up with good cooling and dust-free air, they just sit there and work. They can perhaps be slightly underclocked and undervolted too at say 85% to run for a longer number of years. Same for the memory clock and power draw of the GPU. If any replacement was needed, it's a small part of someone's job.
