Subj : Re: Windows vs Linux To : tenser From : boraxman Date : Mon Apr 25 2022 23:58:15 te> I know a lot of Linux, BSD, and yes, Windows kernel developers. te> What you are describing is simply not accurate. te> te> bo> I've worked almost exclusively with Windows machines in my profession te> bo> career, and my job involves information, being an "information worker te> bo> myself, someone who does most of their job on a computer. te> te> I see. So you haven't had an opportunity to evaluate te> equivalent Linux (or whatever) options in a professional te> context. Why then, make claims about them, or for te> that matter, about Linux? te> Because I have made similar solutions at home. I know how to solve these problems, the tools are lacking te> You are certainly entitled to your opinion, but raising te> concerns that somehow "Linux" will change directions and te> become hostile to the sorts of customizations you like te> to do with it if it becomes more popular is a bit much. te> Perhaps, but there is a war on general purpose computing, and I don't trust Silicon Valley one iota. Perhaps my skepticism is greater than warranted, but it is better to err this way, than being too trusting. te> What you are describing is a bad, inefficient situation. te> However, you are creating a logical fallacy by asserting te> that a) this is due to Windows (or something; I'm not te> quite sure) and b) that the situation would be different te> with Unix/Linux (or something; again, I'm not quite sure). te> te> Indeed, I'm having a hard time understanding how that te> relates to Linux/Unix/whatever. Is your argument that te> you would like an open, or even "free" solution so that te> you wouldn't be tied to whatever vendorware you're being te> subjected to? If so, I could see that as an argument, te> with some caveats: you need people that are both te> sufficiently talented and sufficiently incentivized to te> support that software. te> I saying that this state of affairs it the result of a computing paradigm which was cemented early on. Windows simply is the prime OS involved, because for almost everyone, their picture of how a computer operates was determined by one company, with a scant few seeing the Apple way. Even when I moved away from Windows, and at that time I was a "power user", having written DOS batch files, code in C, BASIC and Assembler, used BBS's, built my own computer, I held a wide variety of assumptions of how computers work which weren't fundamentally true. te> Or is your argument that you think this big pile of bad te> software (a friend likes to refer to such as, "the compost te> heap") could be replaced with a handful of shell scripts te> and some pipelines? If that's the case, I seriously doubt te> it. te> My argument is that this approach is wrong headed, because people are approaching this problem with a very limited scope and understanding of the capabilities of the machine to address their problem. By machine, I don't mean "Windows" or "Fedora", but the hardware itself. The general constraint is to only consider solutions which present themselves as complete application packages or suites. I suggest that we should view the system itself as the suite, and the software as modules. te> Uh ok. What does that have to do with anything at discussion te> here? One of the things Linux can do that Windows cant' Actually run on my computer! te> I have a VAX 4000 down in my basement that won't run Linux. te> I don't think that's an indictment of the Linux developers. te> Comparing a VAX 4000 in terms of ubiquity to mass produced consumer desktop PC's is just disengenuous. That argument is laughable. te> Now you're mixing things. Do you want to write shell pipelines te> using the Unix model (something, I'll note, you can do with te> PowerShell -- which also understands structured data), or do te> you want a graphical experience, in which case, why not invest te> in the native Windows ecosystem? te> te> Saying that it "takes more effort" is subjective. I know te> lots of scientists and engineers who'd rather not futz te> about editing text files to customize things. Perhaps te> that is easier for you, and that's fine! But it is a te> mistake to assume that it is easier for everyone else, too. te> te> Nonsense; plenty of people do. Absolute statement trivially te> disproven by a single empirical example. te> Perhaps in your experience you haven't encountered anyone te> who can see a better way, but I have. What you are describing te> is a _preference_. And again, that's fine, but it does not te> mean a universal truth. te> I brought up a specific problem and discussed how to to solve these problems, an approach which could implement a better solution, and you decide to bring scientists who don't want to fiddle with text files. I work in a science related field, that is my formal education. I work with others educated in science, and it is not US that have to edit config files. It is those that provide the IT infrastructure who's responsibility is to make it go. --- Mystic BBS v1.12 A47 2021/12/24 (Linux/64) * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101) .