Ok, please enlight me how I can install something in my home directory via apt-get?
Check the man pages for apt-get and dpkg. However, it won't work well, not because apt doesn't support it, but because it's a bad idea.
The correct solution is either to use union mounts or user-mode virtualization, or just to give users limited privileges to install new software globally, depending on the environment. Both are widely used for this purpose.
They should provide a package for Linux,
No, they shouldn't. They probably will, at some point, but they shouldn't because that would reduce Linux to the same kind of mess that Macintosh is reduced to.
Sadly Linux still hasn't a standard form to disto independendly package something,
So, why don't FreeBSD, CMU Mach, and OS X have a distro independent package system? In fact, the Macintosh operating system is so inconsistent that I can't even run my Macintosh applications on CMU Mach or FreeBSD. Obviously, if Apple can't get that right, Macintosh isn't ready for the real world yet. No wonder it has a smaller installed base than Linux...
The reason there isn't more FOSS on the Mac is because porting to it is a pain. And Apple likes it that way. Just look at what happened with OpenOffice: Apple sabotaged any solution other than a native port.
Apple is scared stiff that if they make it easy to port FOSS GUI applications to Macintosh, the platform will lose its developers and its distinctiveness. And they are probably right to be scared. But it won't help.
Yeah, just those irrelevant toy applications like Office and Photoshop. Come on.
Bad dependency management on a platform doesn't lead to "toy" applications, it leads to bloatware, as every vendor packs everything into every application. Photoshop and Office are actually good examples of that--that's why those systems come with their own toolkits, libraries, development environments, and scripting languages.
Under OS X, I just drag the applicaiton to the trash and empty it. No more program.
Yeah, the program is gone, but the install isn't necessarily gone. The software may have modified system settings, installed shared libraries, installed daemons, changed file associations, and done a lot of other things. Other software may depend simply on being able to invoke the application. Dragging.app directories into the trash is playing Russian roulette with your system.
Most users will ignore any desktop program that comes in an installer.
Yes; that's because most users that actually need more complex software configurations have long ago abandoned the platform because it doesn't support it well.
The thing that you can find in Control Panel > Software. It's far from perfect, but at least it lets me see all the installed software on a system and remove it with a single mouse click. It's not as nice as Linux package managers, but it's a whole lot nicer than Macintosh, where I have to go hunting around the file system and can never be sure whether dragging the application into the trash will actually remove all traces of it (in fact, it won't).
Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.
Macintosh and Windows both permit, but don't require, applications to modify global system directories on install. Applications that do will be susceptible to this on either platform. So, there is no intrinsic difference between Windows and Macintosh in this area.
Install your own X system, then try to install X app from debian. It requires their install of X.
Debian X11 apps have dependencies on Debian X11 client libraries, as they should; that's what dependencies mean. If you want to ignore those dependencies during an install, just tell apt-get to ignore dependencies; it has flags for that.
There is a way to fake it, but after hours of trying, I failed.
I see no reason why that should be any easier than it is. What you want to do, ignore dependencies, will likely not do what you want, and that's not Debian's fault.
The correct thing to do is to let Debian install its dependencies and install your copy of X11 separately in/usr/local. If you are foolish enough to want existing packages to use your new shared library, use LD_PATH.
Both of the aboves gives you a pretty good summary of why Debians way of handling packages isn't really any good in the long run.
Select in the menu bar Applications > System Tools > Synaptic Package Manager. It prompts you for the system admin password. Then you get point-and-click simplicity for installs.
It's a GUI interface just like you would be using on Macintosh if Macintosh actually had decent package management.
First of you can't install a application as a user, now how stupid is that?
The Debian package manager has provisions for that, but people usually don't bother.
Software packaging should be done by those that provide the software in the first place, the distro might run a quality check on it, but thats it.
And that's why you can point your Debian feeds at whatever source you like. For example, Adobe could provide a Debian feed for Photoshop. And that capability is widely used.
The article fails to make a plausible argument in which OS X would be a threat to Linux any more now than it was before.
Apple's laptops and desktops are already sexy, not too expensive, and fast enough. This move won't entice any new users because it won't change the user experience appreciably. Almost anybody who prefers OS X to Linux will already have switched. Basing their machines on Intel chips won't change that equation.
What switching to Intel will accomplish is that it will make Macintosh hardware a nicer platform for people like me, people who prefer Linux but like the look of Apple hardware. With PPC, Macintosh was a second-class Linux machine because a lot of Linux software would not run on it; with x86, it's a great alternative to PCs.
Another big effect of switching to Intel processors is to dilute Apple's distinctive brand. It may mean more software availability for OS X (via Linux emulators, easier ports in particular of compilers), but that software won't be OS X native software.
There is nothing "simple" about having a different package upgrade mechanism for every program.
If developers DO require more functionality, they can put that extra code into libraries that are inside the application bundle. Since it's usually very application-specific code, it's not going to be something that other apps are going to need/want, so there's no issues with wasted space due to non-dynamic libraries.
You're confusing cause and effect. It's not that Apple has magically figured out which packages make most real-worlddevelopers happy, it's that Apple's developer and user community has become reduced to a group of people that happen to be happy with very little. For a regular UNIX user, the Macintosh is painfully limiting.
There almost certainly are links between inheritance and "intelligence". But establishing them and establishing causality is going to be tricky and will require a lot more careful work than this. This work seems to be at the level of wild speculation, and that's not a prudent thing to do when discussing sensitive issues like race and "intelligence".
I put "intelligence" in quotes because, so far, nobody really knows how to define it, other than "what people score on intelligence tests"; the connections and speculations regarding intelligence made in the paper are untenable. And causality may turn out not to be all that interesting. Rather than "overclocking", metabolic defects may simply close off most career options.
Scientists should look at this problem carefully. These people, I think, have disqualified themselves with this publication. And it might be prudent for Western researchers to pick issues that aren't as burdened with historical baggage as the success and intelligence of Ashkenazi Jews.
The need to archive large quantities of high-quality images captured with CCDs didn't arise only when photographers finally discovered digital--scientists have been doing this for decades.
You do not need manufacturer-specific formats to do this. There are a bunch of formats you can use that store the data in a vendor-independent form and still let you recover the original data.
The most important thing about such formats is that they need sufficient depth (16 bits per channel), they need a choice of lossless and high-quality lossy compression, and they need space for metadata to annotate them with the color space transformations and interpolation method that transformed the original image into the portable image.
Even if none of the existing standard archival formats fit for these needs, it is far easier to define a new format than to try to keep track of zillions of proprietary raw formats.
By converting, for example, to JPEG and throwing the RAW away you are losing lots of creative post-processing control.
Indeed, you are. That's because JPEG doesn't have the depth and gamut to represent digital images captured by modern cameras. If you use a more modern cooked, open format (e.g., TIFF, JPEG2000) at the right depth and at a lossless or high quality setting, then you lose nothing.
Later you may want to re-process the picture with superior software (it does get better over time).
And you can do that because the interpolation from raw to RGB is invertible given a tiny bit of metadata (metadata you would need to carry around with the raw image as well). If you are dealing with a four channel sensor, you can still store the data in a four channel TIFF. No need to store RAW.
Or perhaps you just needed to tweak the white balance.
You can do that in RGB.
Or fiddle with the sharpening.
For professional archival applications, you should turn off in-camera sharpening. That has nothing to do with whether you use raw storage.
Or the tone curve.
You can do that on the cooked image just as easily as on the raw.
I think the whole confusion arises because people like you equate non-raw storage with JPEG. JPEG is a bad choice for high-quality archival storage, but formats like TIFF and JPEG2000 are fine.
Early versions of Xenix were not very Unixish and felt very kludged together. No symlinks, no initab, no vi, short filenames, etc.
Xenix was a port of Bell Labs code. And those restrictions are actually very UNIXish. Symlinks, initab, vi, and long filenames were Berkeley and/or SysV additions, generally not much liked by the original creators of UNIX.
Well, in the case of Apple, DOS was specifically positioned not an operating system, but rather a Disk Operating System, simply the minimal code to access the floppy drives.
Whatever it was positioned at, it was poorly executed. Apple DOS wasn't a good system for what it was (and I disassembled the whole thing at the time). Neither was Integer Basic or the rest of the ROM. The people who created those systems were learning on the job and they were cutting corners all over the place with no idea of what ramifications that would have a couple of years down the road.
By the time you had 64k of memory, you did have enough of a system to run a real operating system, but early PCs didn't have that in the base configuration and that much memory was terribly expensive.
The original PC shipped with a choice of 16k or 64k RAM and a decent-sized ROM. And by the time the PC shipped, 64k was not terribly expensive anymore anyway.
We have nice lossy and lossless image compression formats. There is NO reason ever to bother with raw camera images for archival storage.
Raw image may theoretically contain a tiny bit more information under some circumstances. But you have a cost/benefit tradeoff: store and manage terabytes of raw images indefinitely vs. just achieving the same quality by using higher quality imagers together with standard image formats. Both store the same amount of information in the long run, but the latter is the better economic tradeoff.
Security descriptors, the flexible file system architecture, driver architecture, access control lists, graphics subsystem in the kernel, wannabe-microkernel, etc. The list goes on and on. It gets even worse in Longhorn and with features like WinFS. Microsoft frequently makes the mistake of thinking that more features and more buzzwords equals a better design. Any hot idea in the community gets stuffed into the kernel, with no rhyme or reason, and their nearly unlimited resources lets them pursue this kind of folly.
The UNIX group at Bell Labs had vision, ideas, and taste. The NT group at Microsoft merely has lots of money. And that's how they will go down in computing history.
ant bad implemented?
Well, you only have to use it to see that. For example, interactive response on a loaded NT/XP system is poor, and it has other real-world performance problems. They do seem to be really good at artificial benchmarks, however.
Microsoft doesn't get to tell hardware manufacturers that their hardware must ship with Microsoft's hypervisor. Hardware manufacturers get to decide what software their hardware ships with.
I wouldn't mind a Half Life movie--that video game had far more interesting characters in it. Morrowind has a bit more potential, too. Even Myst. But Halo just never struck me as a particularly interesting story, even for a video game.
Long ago, the instruction set of a chip determined its architecture, but that's not the case anymore. Today, x86 chips are a thin layer of instruction translation on a thoroughly modern core. That's why the x86 chips can beat PPC. So, don't worry about it: chip designers don't have to keep any feet in any buckets.
Your statements are complete non-sequiturs. I claimed none of those things you felt compelled to respond to.
I stand by my statements:
A Z80 is perfectly capable of running a multitasking OS with a hierarchical file system and a well-designed API.
And even the first 8086 was perfectly capable of running a 16bit UNIX-like OS.
(Incidentally, the 8088 was basically just an 8086 with an 8bit data bus. And a poor hardware choices was just as much a sign of incompetence as poor OS design. I remember moaning about IBM's choice of the 8086/8088 family at the time.)
Yes, I ran Xenix, I ran P-System, I ran CP/M. These were good OSes, but they were also nothing like a "multitasking OS with a hierarchical file system and a well-designed API". That didn't happen until much later.
Xenix was UNIX. In any case, my point is that many of the early PC operating systems were not good OSes even though people had had 20 years of experience of how to build good OSes. The people at Microsoft and Apple just did not know what they were doing.
So am I, and I think the best tool for both desktop and server at this point is something in the UNIX family (Linux, BSD, etc.) with one of the X11-based desktops (Gnome, KDE, etc.).
The NT kernel is just a bloated design (and an even worse implementation).
There is one thing Microsoft has done well recently: C#, a Java derivative that fixes many of the most annoying problems of Java. Unfortunately, they are spoiling it with the same kind of poor library design that already made their C++-based environments so miserable.
These people said that there was a "shortage" of programmers and it would last until, what, 2010? And yet there's still a bunch of us who had to get jobs at Home Depot.
There are lots of different kinds of programmers; perhaps your qualifications don't meet what's in demand.
I'm hearing more and more people (even from IT) training to become nurses because of the increased salaries.
The limitations of the machines are no excuse. A Z80 is perfectly capable of running a multitasking OS with a hierarchical file system and a well-designed API. And even the first 8086 was perfectly capable of running a 16bit UNIX-like OS.
(Also, it's not fair to name CP/M and MS-DOS in one breath; CP/M was far better designed.)
In fact what happened is that the companies that did what you like all went out of business and only the hackers at Apple and Microsoft survived.
If you walk into a bank with a machine gun, mow down all the tellers, and take the money, you also survive and get rich, while everybody else dies. That doesn't make your action the best possible action from the point of view of the rest of the world.
You act as if the world would be different today if only Visicalc had been written in Ada.
The problem with DOS and MacOS wasn't that they were written in assembly language (in fact, large parts of MacOS were cross-compiled from Object Pascal), it was that they were designed poorly and rushed to market.
And you are absolutely right that rushing shit to market is a successful business strategy. That makes the people who do that sort of thing good business people, it does not make them competent software developers (even if they fancy themselves that).
Slashdot Mirror
Ok, please enlight me how I can install something in my home directory via apt-get?
Check the man pages for apt-get and dpkg. However, it won't work well, not because apt doesn't support it, but because it's a bad idea.
The correct solution is either to use union mounts or user-mode virtualization, or just to give users limited privileges to install new software globally, depending on the environment. Both are widely used for this purpose.
They should provide a package for Linux,
No, they shouldn't. They probably will, at some point, but they shouldn't because that would reduce Linux to the same kind of mess that Macintosh is reduced to.
Sadly Linux still hasn't a standard form to disto independendly package something,
So, why don't FreeBSD, CMU Mach, and OS X have a distro independent package system? In fact, the Macintosh operating system is so inconsistent that I can't even run my Macintosh applications on CMU Mach or FreeBSD. Obviously, if Apple can't get that right, Macintosh isn't ready for the real world yet. No wonder it has a smaller installed base than Linux...
The reason there isn't more FOSS on the Mac is because porting to it is a pain. And Apple likes it that way. Just look at what happened with OpenOffice: Apple sabotaged any solution other than a native port.
Apple is scared stiff that if they make it easy to port FOSS GUI applications to Macintosh, the platform will lose its developers and its distinctiveness. And they are probably right to be scared. But it won't help.
Yeah, just those irrelevant toy applications like Office and Photoshop. Come on.
Bad dependency management on a platform doesn't lead to "toy" applications, it leads to bloatware, as every vendor packs everything into every application. Photoshop and Office are actually good examples of that--that's why those systems come with their own toolkits, libraries, development environments, and scripting languages.
Under OS X, I just drag the applicaiton to the trash and empty it. No more program.
.app directories into the trash is playing Russian roulette with your system.
Yeah, the program is gone, but the install isn't necessarily gone. The software may have modified system settings, installed shared libraries, installed daemons, changed file associations, and done a lot of other things. Other software may depend simply on being able to invoke the application. Dragging
Most users will ignore any desktop program that comes in an installer.
Yes; that's because most users that actually need more complex software configurations have long ago abandoned the platform because it doesn't support it well.
Thirdly, *what* Windows XP package manager?
The thing that you can find in Control Panel > Software. It's far from perfect, but at least it lets me see all the installed software on a system and remove it with a single mouse click. It's not as nice as Linux package managers, but it's a whole lot nicer than Macintosh, where I have to go hunting around the file system and can never be sure whether dragging the application into the trash will actually remove all traces of it (in fact, it won't).
Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.
Macintosh and Windows both permit, but don't require, applications to modify global system directories on install. Applications that do will be susceptible to this on either platform. So, there is no intrinsic difference between Windows and Macintosh in this area.
Install your own X system, then try to install X app from debian. It requires their install of X.
/usr/local. If you are foolish enough to want existing packages to use your new shared library, use LD_PATH.
Debian X11 apps have dependencies on Debian X11 client libraries, as they should; that's what dependencies mean. If you want to ignore those dependencies during an install, just tell apt-get to ignore dependencies; it has flags for that.
There is a way to fake it, but after hours of trying, I failed.
I see no reason why that should be any easier than it is. What you want to do, ignore dependencies, will likely not do what you want, and that's not Debian's fault.
The correct thing to do is to let Debian install its dependencies and install your copy of X11 separately in
Both of the aboves gives you a pretty good summary of why Debians way of handling packages isn't really any good in the long run.
Select in the menu bar Applications > System Tools > Synaptic Package Manager. It prompts you for the system admin password. Then you get point-and-click simplicity for installs.
It's a GUI interface just like you would be using on Macintosh if Macintosh actually had decent package management.
First of you can't install a application as a user, now how stupid is that?
The Debian package manager has provisions for that, but people usually don't bother.
Software packaging should be done by those that provide the software in the first place, the distro might run a quality check on it, but thats it.
And that's why you can point your Debian feeds at whatever source you like. For example, Adobe could provide a Debian feed for Photoshop. And that capability is widely used.
The article fails to make a plausible argument in which OS X would be a threat to Linux any more now than it was before.
Apple's laptops and desktops are already sexy, not too expensive, and fast enough. This move won't entice any new users because it won't change the user experience appreciably. Almost anybody who prefers OS X to Linux will already have switched. Basing their machines on Intel chips won't change that equation.
What switching to Intel will accomplish is that it will make Macintosh hardware a nicer platform for people like me, people who prefer Linux but like the look of Apple hardware. With PPC, Macintosh was a second-class Linux machine because a lot of Linux software would not run on it; with x86, it's a great alternative to PCs.
Another big effect of switching to Intel processors is to dilute Apple's distinctive brand. It may mean more software availability for OS X (via Linux emulators, easier ports in particular of compilers), but that software won't be OS X native software.
Ah, but you miss the point of OS X's simplicity.
There is nothing "simple" about having a different package upgrade mechanism for every program.
If developers DO require more functionality, they can put that extra code into libraries that are inside the application bundle. Since it's usually very application-specific code, it's not going to be something that other apps are going to need/want, so there's no issues with wasted space due to non-dynamic libraries.
You're confusing cause and effect. It's not that Apple has magically figured out which packages make most real-worlddevelopers happy, it's that Apple's developer and user community has become reduced to a group of people that happen to be happy with very little. For a regular UNIX user, the Macintosh is painfully limiting.
There almost certainly are links between inheritance and "intelligence". But establishing them and establishing causality is going to be tricky and will require a lot more careful work than this. This work seems to be at the level of wild speculation, and that's not a prudent thing to do when discussing sensitive issues like race and "intelligence".
I put "intelligence" in quotes because, so far, nobody really knows how to define it, other than "what people score on intelligence tests"; the connections and speculations regarding intelligence made in the paper are untenable. And causality may turn out not to be all that interesting. Rather than "overclocking", metabolic defects may simply close off most career options.
Scientists should look at this problem carefully. These people, I think, have disqualified themselves with this publication. And it might be prudent for Western researchers to pick issues that aren't as burdened with historical baggage as the success and intelligence of Ashkenazi Jews.
The need to archive large quantities of high-quality images captured with CCDs didn't arise only when photographers finally discovered digital--scientists have been doing this for decades.
You do not need manufacturer-specific formats to do this. There are a bunch of formats you can use that store the data in a vendor-independent form and still let you recover the original data.
The most important thing about such formats is that they need sufficient depth (16 bits per channel), they need a choice of lossless and high-quality lossy compression, and they need space for metadata to annotate them with the color space transformations and interpolation method that transformed the original image into the portable image.
Even if none of the existing standard archival formats fit for these needs, it is far easier to define a new format than to try to keep track of zillions of proprietary raw formats.
By converting, for example, to JPEG and throwing the RAW away you are losing lots of creative post-processing control.
Indeed, you are. That's because JPEG doesn't have the depth and gamut to represent digital images captured by modern cameras. If you use a more modern cooked, open format (e.g., TIFF, JPEG2000) at the right depth and at a lossless or high quality setting, then you lose nothing.
Later you may want to re-process the picture with superior software (it does get better over time).
And you can do that because the interpolation from raw to RGB is invertible given a tiny bit of metadata (metadata you would need to carry around with the raw image as well). If you are dealing with a four channel sensor, you can still store the data in a four channel TIFF. No need to store RAW.
Or perhaps you just needed to tweak the white balance.
You can do that in RGB.
Or fiddle with the sharpening.
For professional archival applications, you should turn off in-camera sharpening. That has nothing to do with whether you use raw storage.
Or the tone curve.
You can do that on the cooked image just as easily as on the raw.
I think the whole confusion arises because people like you equate non-raw storage with JPEG. JPEG is a bad choice for high-quality archival storage, but formats like TIFF and JPEG2000 are fine.
Early versions of Xenix were not very Unixish and felt very kludged together. No symlinks, no initab, no vi, short filenames, etc.
Xenix was a port of Bell Labs code. And those restrictions are actually very UNIXish. Symlinks, initab, vi, and long filenames were Berkeley and/or SysV additions, generally not much liked by the original creators of UNIX.
Well, in the case of Apple, DOS was specifically positioned not an operating system, but rather a Disk Operating System, simply the minimal code to access the floppy drives.
Whatever it was positioned at, it was poorly executed. Apple DOS wasn't a good system for what it was (and I disassembled the whole thing at the time). Neither was Integer Basic or the rest of the ROM. The people who created those systems were learning on the job and they were cutting corners all over the place with no idea of what ramifications that would have a couple of years down the road.
By the time you had 64k of memory, you did have enough of a system to run a real operating system, but early PCs didn't have that in the base configuration and that much memory was terribly expensive.
The original PC shipped with a choice of 16k or 64k RAM and a decent-sized ROM. And by the time the PC shipped, 64k was not terribly expensive anymore anyway.
We have nice lossy and lossless image compression formats. There is NO reason ever to bother with raw camera images for archival storage.
Raw image may theoretically contain a tiny bit more information under some circumstances. But you have a cost/benefit tradeoff: store and manage terabytes of raw images indefinitely vs. just achieving the same quality by using higher quality imagers together with standard image formats. Both store the same amount of information in the long run, but the latter is the better economic tradeoff.
And how exactly is it bloated
Security descriptors, the flexible file system architecture, driver architecture, access control lists, graphics subsystem in the kernel, wannabe-microkernel, etc. The list goes on and on. It gets even worse in Longhorn and with features like WinFS. Microsoft frequently makes the mistake of thinking that more features and more buzzwords equals a better design. Any hot idea in the community gets stuffed into the kernel, with no rhyme or reason, and their nearly unlimited resources lets them pursue this kind of folly.
The UNIX group at Bell Labs had vision, ideas, and taste. The NT group at Microsoft merely has lots of money. And that's how they will go down in computing history.
ant bad implemented?
Well, you only have to use it to see that. For example, interactive response on a loaded NT/XP system is poor, and it has other real-world performance problems. They do seem to be really good at artificial benchmarks, however.
Even if Linux weren't as stable as it is, I'd prefer its convenience to Windows. Windows is just a royal pain.
Microsoft doesn't get to tell hardware manufacturers that their hardware must ship with Microsoft's hypervisor. Hardware manufacturers get to decide what software their hardware ships with.
I wouldn't mind a Half Life movie--that video game had far more interesting characters in it. Morrowind has a bit more potential, too. Even Myst. But Halo just never struck me as a particularly interesting story, even for a video game.
Long ago, the instruction set of a chip determined its architecture, but that's not the case anymore. Today, x86 chips are a thin layer of instruction translation on a thoroughly modern core. That's why the x86 chips can beat PPC. So, don't worry about it: chip designers don't have to keep any feet in any buckets.
I stand by my statements:
(Incidentally, the 8088 was basically just an 8086 with an 8bit data bus. And a poor hardware choices was just as much a sign of incompetence as poor OS design. I remember moaning about IBM's choice of the 8086/8088 family at the time.)
Yes, I ran Xenix, I ran P-System, I ran CP/M. These were good OSes, but they were also nothing like a "multitasking OS with a hierarchical file system and a well-designed API". That didn't happen until much later.
Xenix was UNIX. In any case, my point is that many of the early PC operating systems were not good OSes even though people had had 20 years of experience of how to build good OSes. The people at Microsoft and Apple just did not know what they were doing.
I'm a big fan of the "best tool for the job".
So am I, and I think the best tool for both desktop and server at this point is something in the UNIX family (Linux, BSD, etc.) with one of the X11-based desktops (Gnome, KDE, etc.).
The NT kernel is just a bloated design (and an even worse implementation).
There is one thing Microsoft has done well recently: C#, a Java derivative that fixes many of the most annoying problems of Java. Unfortunately, they are spoiling it with the same kind of poor library design that already made their C++-based environments so miserable.
These people said that there was a "shortage" of programmers and it would last until, what, 2010? And yet there's still a bunch of us who had to get jobs at Home Depot.
There are lots of different kinds of programmers; perhaps your qualifications don't meet what's in demand.
I'm hearing more and more people (even from IT) training to become nurses because of the increased salaries.
That's scary: medical care like IT help desks...
and the problem would be what exactly?
The limitations of the machines are no excuse. A Z80 is perfectly capable of running a multitasking OS with a hierarchical file system and a well-designed API. And even the first 8086 was perfectly capable of running a 16bit UNIX-like OS.
(Also, it's not fair to name CP/M and MS-DOS in one breath; CP/M was far better designed.)
In fact what happened is that the companies that did what you like all went out of business and only the hackers at Apple and Microsoft survived.
If you walk into a bank with a machine gun, mow down all the tellers, and take the money, you also survive and get rich, while everybody else dies. That doesn't make your action the best possible action from the point of view of the rest of the world.
You act as if the world would be different today if only Visicalc had been written in Ada.
The problem with DOS and MacOS wasn't that they were written in assembly language (in fact, large parts of MacOS were cross-compiled from Object Pascal), it was that they were designed poorly and rushed to market.
And you are absolutely right that rushing shit to market is a successful business strategy. That makes the people who do that sort of thing good business people, it does not make them competent software developers (even if they fancy themselves that).