What, can’t you just… idk, check better to see how clean it actually is? That can’t be right, you probably got your samples contaminated. Were those really from that machine? Maybe you got them mixed up. Well you’re really itching to find contaminants, aren’t you? Of course you’ll find something if you look hard enough…
I don’t know how your business works, so I’m trying to project the managers I know onto it - am I so far off that I look like a manager?
As a Data Analyst / Business Analyst, let me assure you: Not all of us are stupid (some are, for sure), but there’s only so much you can do about stupid managers. If they decide that a certain measure is key, it can be really hard to explain why it isn’t that important or where a certain distortion comes from. To compound this, some managers genuinely don’t understand their business processes and are unwilling to have it explained to them. They’ll make assumptions about how things work, then base their demands on those.
For an entirely made up example, consider a department manager looking to monitor a software development team’s workload. That workload, to them, consists of bug tickets and feature implementations. Not counted here are feature requests because, apparently, fielding them and discussing their feasibility isn’t actual development work. That’s management work, which is the Product Manager’s job… Except the Product Manager can’t unilaterally decide whether something is feasible without consulting those actually familiar with the code, taking up the developer’s time. On the other hand, since it’s an internally developed tool for other units, they can’t just say No to every request or else they risk people calling their team’s funding into question.
Now, you have the choice between frustrating yourself and annoying the manager by trying to explain all that, or gritting your teeth and just giving them the stupid chart on bugs closed and feature implementations completed over time. Guess which one is healthier for your employment prospects?
And we haven’t even started talking about the variance in effort of bug fixes or about non-feature work for code stability or QA. Eventually, we’ll reach the point where the measure becomes a target and you have to start reframing bug fixes as features and splitting features up into smaller features just to make the figures look nicer.
What I’m getting at is this: Sometimes, the analysts aren’t to blame, but the managers making decisions.
That’s not to say there aren’t absolutely shitty business analysts out there that will gladly figure out ways to polish the figures and then cash the check for making the figures look better.
“China runs it? I want nothing to do with it!”
Stupid, to be sure, but he’s not running on rational, but emotional reasoning.
You can block them, btw.
I just love how this whole affair and people* using autism as an apology just makes it seem like autists are all braindead, naive and entirely unaware that the way we behave and ourselves communicates something about us. We might not always know just what it communicates or how we ought to behave to communicate, but I’m pretty sure it I did my best impression of some figure I adore, I’d do it in the full knowledge that it communicates “I like this figure and I wish to be like them”.
*not you, I understand your comment to be a parody, but the pattern it parodies obviously exists
Ethanol with grape flavouring
You said something about security patching, testing and production. I thought I’d let you know that those three words don’t really go together.
“Production” implies a professional environment, where “testing” usually applies to the newly added features (and if you’re lucky, to past features or even regression tests against bugs) but to my knowledge never to security. Security patching does happen, but I’ve never seen it tested before applying it in professional environments. And finally, the one instance I know where security patches were tested before applying them was in a college course, that is: not a professional, productive context.
Should you?
Yes, please. I’m running out of stories to go with my popcorn. All I’ve got are the type that would go with a tub of comfort ice cream (or a strong drink, if that’s your poison).
In that case, let me add a few more details:
Deb packages have dependencies on other packages. To install and run a given application, you will have to install other packages (typically libraries the app depends on) too. In the case of using apt, you may see it show a list of packages to install, even when you asked for just one - those other packages are things the one you asked for requires.
These packages are shared across apps. If I install one app that requires a specific graphics library, then later install another that requires the same library, it won’t have to install it again. On the other hand, if some library introduces changes that break something, updating that shared library because one app requires a newer version may break a different app which required the old version and isn’t compatible with the new one.
Snaps on the other hand are self-contained: All the dependencies are included with the snap, frozen into whatever version the snap author chose. You can have multiple different versions of the same snap installed in parallel, and each will have their dependencies isolated from each other and the rest of the system. Additionally, they come with certain security measures like restricting the app’s access to the filesystem, network, display etc.
As a downside, snaps can be larger (but don’t have to be, as they can be stored compressed because the dependencies don’t need to be available elsewhere) and take a little longer to start (though this has apparently been much improved).
So they’re not generally a bad thing, all in all. I understand their advantages, I respect that they can be a comfortable solution for devs, I like the idea behind the security measures.
For my personal experience:
I recall that the Firefox snap had issues as opposed to the deb (among other things, the startup time was atrocious for me), which was how my issues with it started, because it took some effort to figure out how to get a deb version again and make sure I kept getting deb versions. Some other app - I don’t recall which one - also had persistent lag issues which were apparently due to some permissions problem, where security evidently hamstrung usability.
Accordingly, I was somewhat disgruntled with having my working app ripped out from under me and replaced with a worse one and no comfortable way to get back. I had issues with my Firefox profile too, which turned out to be user error on my part, but obviously still annoyed me in absence of an easy migration mechanism between the two.
Again, these issues may be fixed now, and they might not be issues for everyone in the first place: if you start out with the snap, migration won’t be an issue, and if it runs well, it may well be a better solution for you. I personally resent the philosophy of “Here, let me assume you want a different thing and just swap it out for you”, but you don’t need to share that resentment.
To expand on the hate of snaps:
They’re a packaging solution for apps and dependencies. They’re apparently quite comfortable for app developers to use too. There was a hiccup where some apps really struggled to run well as snaps, but AFAIK that was fixed.
The common issues are snapcraft being the only repository and the methods of pushing them:
Snapcraft is where the packages are stored and loaded from, and it’s a closed-source repo hosted and controlled by Canonical, with no option to configure snap to use a different source. That has advantages for security, if you trust Canonical to vet and take responsibility for the packages on their system, but some people chafe at that lack of control. Compare to flatpak, where you can add arbitrary repos, so any distro vendor can have their own set of packages and versions they’ve vetted for stability and compatibility, but if I want a different version than my vendor maintains in their remote, I can use a different remote for certain apps instead.
The second issue is that the classical apt system, which used to install .deb packages, was utilised to install snaps instead, so you’d run apt install package and expect a .deb to be installed, but instead it just downloads a script that runs snap install package and you get a snap instead, which is particularly annoying when you previously had it as a deb and it suddenly gets replaced. The argument here is a smooth transition to the “better” system, on the premise that snaps are better and the assumption that users won’t care or notice. In some cases (the hiccups mentioned earlier) that just wasn’t the case and people got frustrated, but even if it worked, some people (including me) take issue with expecting a deb and getting a snap - if I want a snap, I’ll use snap, and if your deb is deprecated, offer me to switch instead of silently installing the alternate source instead.
What would you prefer then? For Firefox to stop existing, so that we all finally have to use Chromium?
So because they take money from Google but don’t effectively challenge the monopoly, they ought to be done away with? All Hail our Chromium overlords!
I agree that the exec salaries could use a heavy trimming to the benefit of their actual R&D, but right now, they’re the biggest challenger to the dominance of Chromium. They could be better, sure, but I’d rather have mediocrity than no choice at all.
How would you recommend anyone measure this?
Not at all, that’s my point. We can’t measure absence.
So far the answer has been things like nvidia drivers and “anti-cheat doesn’t work”, which are things out of our control.
For the cases you get an explicit reason, yes. Again, we can’t measure or evaluate data that isn’t there. We can’t know how many potential users just weren’t convinced by the pitch.
If you don’t understand what something is, it may be that you are not the target audience!
So the target audience for Bazzite are people familiar with cloud-computing based development practices? Otherwise, they wouldn’t make it past the first five words of the pitch “Bazzite is a cloud native image built upon Fedora Atomic Desktops”.
Also, that’s a great way to build walls, but I’d prefer we build bridges and help people understand instead.
Laypeople don’t install operating systems.
Laypeople with respect to OS development or cloud development may well do so. Many Linux users - particularly the share of Windows Gaming converts - have no expertise with “standard cloud tools”, but that doesn’t and shouldn’t be an issue for using Linux.
If it is an issue for using Bazzite, specifically, that would again lead back to the point: Are Gamers in general the target audience, or just a specific subset?
Less technical users don’t care and go download the ISO, they don’t need to care about any of this.
How do you know? Here, we circle back to measuring absence. If less technical users read “cloud” and close the tab, there’s no way of detecting that.
The conventional marketing wisdom is to deliver strong selling points in your pitch. In the absence of statistical ways to test it, I would approach the question from the perspective of the “customer”, assuming that would be gamers: They want gaming, they want stability, they want to not worry about breaking their system. Bazzite can deliver on that, so why not put those points in the pitch instead?
Now, I understand that what you’re doing right now works well enough for you. What I don’t get is the strong reaction to an apparently frequent suggestion to improve a detail. The whole thread started with an unprovoked “the more I see this whining the more I want to keep it on the website.” Instead of eventually reconsidering or just ignoring the complaint, quarterlife felt the need to be explicitly spiteful.
How would you even measure how many are turning away? Do your stats tell you how many people don’t download it? Do they give you feedback on what turned them away? And those who did download it, do they give you feedback whether and how the term influenced their decision?
But that’s all beside my actual point. I may have gotten carried away in my frustration at a recurring issue in the tech space where people proficient with some thing are unwilling to cater to those who aren’t, buillding a wall of required expertise around the good things (software or knowledge) they otherwise produce.
I think it’s an unreasonably pedantic stance to insist on using a correct term at the expense of utility. I’d expect a software description to start with what it does, not how it comes to be, particularly if the “how it comes to be” is abbreviated in an intransparent technical term, linking to a page slapping the unfamiliar with a slew of product terms and technologies rather than an actual explanation of what it means and what bearing it has on the product. Your description as it is now targets tech experts, rather than laypeople, and if other people have also suggested changing the wording to be clearer, it shows that I’m not alone in that assessment.
I feel like the tech environment - and any other knowledge-oriented environment like science or education - is better served if those with more knowledge make an effort to make it accessible to those with less. Thus, I take issue with people doubling down on hiding it behind terms specific to their field and largely unknown outside.
We probably won’t agree on this issue. You feel justified in being technically correct, while I place more value on accessible descriptions for less technical (prospective) users.
Alright, let’s put it in easy words then:
You will continue seeing these comments as long as people with common sense discover Bazzite and don’t immediately turn away at the term.
any professional paid Linux job
a small subset of users (Most of which are going to be Windows Gamers)
So your target audience is the small world of professional cloud developers using Linux, and you don’t expect many other Gamers, Windows or otherwise, to even consider Bazzite? In that case, ride on upon your high horse.
Meanwhile, the rest of us will keep trying to actually attract Windows gamers to Linux and cater to Linux gamers that don’t happen to be working in a specific profession. Bazzite clearly isn’t the right choice for normal people then. Sorry for that misunderstanding.
the website quite literally links to something that says that’s not the case
Why people keep expecting lay-users to confidently stride into technical word-soup and come out with a clear understanding is beyond me, but it definitely tracks with your “professionals only” policy.
And by the way, you actually have to find and click three links to arrive at a technical description that talks about developing and building environments. How does that help the average user? It still tells them nothing about the OS they originally were interested in.
The issue with this kind of buzzword is the multitude of definitions in use. You assume people are familiar with and agree upon yours, thus making it the correct one. But the meaning of words isn’t just dictated by what some people think it means, but by the way many people use them. Thus, Buzzwords used in many contexts primarily to sell something by vague association with something trendy (“cloud”) suffer from a dilution of meaning.
In this case, the OP was confused whether the word means that their system will be running in the cloud rather than their machine at home. So however “correct” your definition may be on paper, it brought no benefit in describing your product.
And that is the heart of the criticism: Don’t rely on snappy buzzwords just because you have one definition for them. Explain that definition too, in case people like the OP don’t know which one you use.
Doubling down on being obtuse does nobody any favours. If people communicate “this term is confusing”, refusing to change it is your right, but spiting good intentions is still immature.
Huh, weird. The IT guys I work with don’t just know Windows, when I joked about wanting a Linux instead they pointed out that we have software devs using Linux too. I’d need some reason to request it, but if I know the right people (and more particularly, what their favourite snacks are), I could probably get it approved.
(Doesn’t actually help me, given I’m stuck using proprietary tools that I couldn’t get to run with wine, but at least the option is there. And that’s a big corp.)
I don’t want is to have it running, or heavily integrated in some proprietary-ish cloud.
It does, just not ours, Valve runs that part. 😼
By this you mean that Steam is pre-installed, thus integrating it with the Valve cloud?
What use is misleading accuracy? Why double down on confusing people?
Just dump it in ~
Couldn’t you just add up the germs found in successive swabs to the total and increase the total count with each test?
(I assume you have certain testing and evaluation standards you’re bound to, so that’s a “No”, but I like the idea of the results getting worse rather than better)
What would newer equipment do differently to make it less prone to hygiene issues?