Or what's the "old and understood" method for an application to receive notification when the disk is full? Or when a USB device is inserted?
I agree with the above sentence (and I completely agree with the GP, he nailed it on the head). The problem I see with modern distros (modern GNU/Linux) is that many of those features that somebody "needs" are being hacked into the system without really thinking about the big picture. Basically, we're just hacking extra stuff into GNU/Linux that somebody wants to have now, because she saw it in a different OS and it seemed nice.
Could you elaborate upon that? Like what's an example of such a system? Why is it not necessary? Or why does it not fit in with the rest of the system?
I have to admit I'm still not too familiar with a lot of this stuff - for instance I don't know much about hald except that it delivers hotplug notifications and such, and most of what I know about dbus I learned yeaterday after a cursory google search. But from what I know so far it generally seems like good stuff.
It's going into the default Debian desktop install. Don't be a pedant.
You got to bear in mind, I think, that a lot of us may have been running Debian for ages, but may not have actually installed it in several years... I know that prior to last year (when I finally moved to AMD64) I had been on the same Debian install for ages... I don't think they had the "install profiles" back then, it was just "install base system" and then select the other stuff you wanted. Using dselect.:)
No, they might be useful someday. Today they are all semi-stable and almost totally undocumented black boxes that upend forty years of UNIX/POSIX tradition yet were pushed into production in this insane quest to be a better Windows than Windows and thus somehow bring about the Year of Linux on the Desktop.
So while all of the old understood ways of configuring a system have been tossed into the trash, the new replacements aren't ready for prime time. By ready I mean 'just works' at least 99% of the time and has clear documentation to permit a skilled UNIX admin to fix that last 1%.
My perspective: I appreciate the history and tradition of Unix/Posix but I don't believe any of it is beyond the need for improvement.
For instance, what's the "old and understood" method for writing an application to which another process can connect at runtime and send commands, or receive notifications? SYSV IPC? Binding to some random port number, hoping nobody else is using it, and waiting for connections? Putting a named pipe somewhere on the filesystem and... (you'll have to forgive me, here - I haven't learned quite enough to know all the details of how to implement a thread-safe application object interface via named pipes...)
Or what's the "old and understood" method for an application to receive notification when the disk is full? Or when a USB device is inserted?
I'm with you to a point: that the changes in how things are done in the last several years have been a bit baffling and hard to keep up with at times. But I feel like in general it's been good stuff. Each time the system gets a bit more coherent, a little better suited to what I want it to do...
I think that's a good summary of the anxieties of end users.
"the greater danger is always simply that the package maintainers will simply stop working on the project."
That's something real and within most people's experience. Yet it doesn't stop us happily using all kinds of stuff which may be deprecated/abandoned in a few years.
Well, in my case it does.:) At least it did when I was thinking of getting set up with some iPhoto-like software... F-Spot's the only one I liked enough to keep it installed - but I didn't go to the extent of cataloguing all my old photos or importing new ones. I should really rethink that, one of these days... F-Spot could very well be the one that's worth the time and effort.
Something like a protracted legal dispute... or a decision by either the FSF or the OSI that mono doesn't meet their definitions of Free or Open Source software. Unless that happens then the people who oppose mono are really wasting their breath.
I wouldn't exactly say they're wasting their breath. They have their own idea of how Linux as a platform should evolve, and to them Mono isn't a part of it. They are advocating (if not in a particularly nice way) their own idea of how things should move forward, and they are having an impact.
The unfortunate bit is that this whole conflict over Mono doesn't get us anywhere. It's progress, in one direction or another, which improves and advances the platform. If Mono were more universally adopted by Linux users, I think that would be a good thing for the platform. For people who want to write commercial applications it represents, among other things, a fairly stable ABI... For the rest of us, it could be a good system infrastructure component - if our culture can accept it.
But there's my dilemma - I feel the Linux platform would benefit from having some more powerful and version-stable components standard - even just from a "hacker" perspective that's valuable. Improving inter-language binding is very valuable, as is providing a generic mechanism applications can use to generate optimized code at runtime. Likewise the potential implications for IPC, application scripting, and so on are all grand. So I believe having a "core component" that does roughly what Mono does would be a great asset. Any candidate that can provide that functionality would be a good thing, and the main criterion that discerns how useful it is would be the adoption rate. So from that perspective, I should stand behind Mono as the prime candidate of a means of providing that functionality - except that I don't like the character of that particular solution, and that matters to me. So it's either embrace something I don't really like to try to promote the benefits it will bring, or don't embrace it, and hope something else that's "more Linuxy" will fill roughly the same role on Linux as.NET does on Windows. But it would take some serious time for all that to happen... like years...
My understanding (I may be wrong and am happy to be corrected) is that the worst that Microsoft could do would be to extend.NET in ways that make projects built on mono incapable of being compatible with.NET.
Really, I don't think anybody would know what Microsoft could do against Mono until/unless they tried... It would be all about how the lawsuit plays out - what's happened so far may not have a great deal of influence upon that.
I don't at all know how likely it is that Microsoft would even try to damage Mono. It seems to me that it all depends on whether they felt they had something to gain from it.
It would be a bigger issue if mono was, like Sun's Java, the basis of important enterprise applications. That doesn't seem to be the case.
It's still fairly new. We may have simply not reached that level of reliance upon it yet. But a tool like Mono - if people aren't relying on it, then it means we're not yet fully taking advantage of it.
Consider the.NET versions of Python and such, for instance: they offer some nice advantages, particularly in terms of integrating Python code and data with code written in other languages. I believe, for instance, that it's quite straightforward to write a Powershell commandlet in IronPython. This is a practical benefit of the.NET platform that Linux doesn't share because of limits in how people are apparently willing to utilize Mono at this point. You won't generally find IronPython on Linux systems, let alone in place of CPython... (Does it even work on Mono? I don't know...)
Gnome and various developers, in house and independent, would have wasted some time and resources. Tomboy is not the only note tool, F-Spot is not the only photo manager and Beagle is not the only meta-search tool.
It's important to look at what that means for those applications now, however: uncertainty about Mono translates to these applications. I know I don't want to invest myself in any photo-management application that I would be unable to rely upon in the future. If I started using F-Spot to manage my photos and then had to stop using it, I don't know where that would leave me in terms of the organization of my photos.
In practical terms, though, I feel like the greater danger is always simply that the package maintainers will simply stop working on the project. That's a risk that exists for any such app, independent of any perceived Microsoft threat.
The one truly effective and practical act that would negate mono would be the development of applications with the same appeal to users and distributions and the Gnome project. Tracker is a reasonable substitute for Beagle. Despite being a fan and a user of Gthumb and Geeqie I wouldn't have the bare-faced cheek to claim they are drop in replacements for F-Spot or even claim to have similar goals or features in many important ways.
Well, it's a lot of work to write an application like that - and for the most part I think it's a waste of time. The motivated developer talent in Linux is spread thinly enough, I think, without having to rewrite perfectly good applications. (Though to a certain extent this is unavoidable - different teams will often take on the same problem and come up with "competing" solutions, each with different advantages - it takes time for any kind of clear winners to emerge...)
Free software relies on all kinds of sources. The GNU system itself was/is a re-implementation of UNIX. Many of the languages used started off as proprietary. There's nothing new in this. Where is the campaign to purge Fortran or Pascal from the free software opus? Why no campaign against Samba and the use of the SMB protocol? Why is nobody outraged at DotGNU? Where are the calls to cease supporting.avi container and other MS developments?
The difference there, to my mind, is the extent to which we come to rely upon these various technologies. If the Samba project were defeated through legal measures by Microsoft (and please don't interpret this as a suggestion that this will happen - it's just a scenario.) then what would we lose? One LAN file sharing protocol out of many, the ability to share files over a LAN with Windows machines without installing any additional software on the Windows machine...
Mono (or DotGNU, if anybody actually used it) present a somewhat different problem: here you've got something which (IMO anyway) Linux sorely lacks: a coherent VM implementation that can be used in the implementation of different scripting languages, a consistent data representation that can be used to help bind different languages together, and additionally C#, which seems like a good language for application development. This places it in a much more critical position if one comes to rely upon it.
It's hard to debate with people when their fundamental position is composed essentially of hatred, fear and dislike of persons or groups. Where is the factual basis? Where is the ability to consider anything useful when hate or fear is the driving force? This is religion by another name, it cannot be reasoned with, it is impervious to contradictory verifiable fact, it allows no deviation.
There is no contradictory verifiable fact. In the end, Microsoft will either use legal means to defeat Mono, or not. Nothing they say or do now actually prevents this from occurring. Likewise there's not much in the way of "factual basis" apart from what Microsoft has done in the past. You are right that this is largely about fear: though personally I am not entirely convinced that this fear is entirely unfounded. Sometimes there's not a lot of solid information to rely upon: in that case there's no choice but to guess, gamble at what will and won't happen in the future.
Personally, I feel like Mono is not necessarily what I signed on for when I chose to use Linux in the first place. It's a petty reason, really, but even such simple things as putting ".exe" on the end of a filename, or using the same file type signature as DOS executables - these aren't things I really want to see on my system. It gives the programs a bit of an alien character. I don't think it's especially sensible in general for compiled programs to run in a VM, for that matter. Matters of taste like this may seem silly but they are relevant, to my mind: if things don't fit my own idea of what I'd like Linux to be, as a system, then I generally won't be too inclined to stand behind them.
Really, any time you try to introduce some critical piece of infrastructure to the system, people will be hesitant to invest themselves in it - they need to be convinced that it's the right thing. Any facet of the system that people don't like will count against it, and stand in the way of people adopting it. It's not enough for a bit of technology to be good - people have to embrace it or its merits won't make a difference.
It's a tough problem for a platform where there's no central authority - how does one make the platform as a whole advance at a fundamental level, when there's no one to lay down the law about how the core components will work? Groups like Gnome or KDE or major distributions like Debian or Ubuntu are about the closest thing we've got to an "authority" to make these decisions stick - honestly it makes me a bit uneasy that Gnome has gone with
*On another note: What's the point of Gnome again, now that Qt/KDE is open sourced?*
To not be a cluttered piece of crap, which is KDE's job. See on UNIX, every program should do one thing and do it well.
I've always thought KDE's applications were much better than OpenOffice - and Gnome doesn't seem to have any productivity applications at all...
(I've run mostly KDE for a long time, though I have been running Gnome of late, on my new laptop - and I'm quite enjoying it...)
I really strongly feel that Unix lacks the coherent infrastructure needed for this "each tool does one thing well" philosophy... If each tool does just one thing, then your ability to accomplish things strongly depends on how effectively and easily you can link multiple tools together... I feel like the old Unix tools philosophy has gone AWOL of late, and it's pretty much absent from the GUI space, where an individual application is usually written to handle all possible actions for an individual problem domain, and there's very little consideration made to linking these applications together...
IMO however, introducing a cable into the mix really doesn't solve the underlying issue that this purports to be. Now instead of a huge compact piece of equipment, you have a huge sprawling piece of equipment with a spiderweb of cords.
Yeah, been there, done that. That was my computer desk around 18 years ago. And you know, it actually worked out rather well - a lot better than it would have if the devices were all sidecars.
I had a Commodore 128 (itself an indecently large machine) with two drives, printer, modem... If I could've afforded a RAM expansion or hard drive, I would have got one. Pretty much all the same gear they showed hooked up to that TI99-4/A except it didn't have to be all connected together in a straight line... So I had the drives off to the right, set back underneath the bookshelf area of my computer desk, I had the printer off to the side on a printer stand (which also housed the mass of tractor-feed paper), and the modem (I used an RS-232 line-level converted and a standard RS-232 modem at the time) off to the left. And because I didn't have to connect the peripherals directly adjacent to the machine, there was room on the right for me to use a mouse or joystick.
Daisy chaining wasn't a huge problem on the Commodores, either - I suppose it might have been if the cables were parallel links rather than serial - but it would've been rare for a drive to fail so completely that it could no longer communicate with the host - and even if it had, it wouldn't have broken the daisy-chain (the bus was wired straight-through)
So I don't think the bulk of the equipment back then was necessarily a huge problem. You just had to organize it nicely, and it was workable. With sidecars your options for "organizing" would have been very limited.
It baffles me sometimes when people choose to get an external hard drive or CD-writer which is then left permanently plugged in to the machine... I mean, the spider-web of cords is workable, but it's still a hassle. Why would you choose that when you've got a nice cozy internal drive-bay for the thing?
Hardly a design mistake. Its more a lack of testing mistake.
No, pretty sure that's a design mistake. The lack of testing is just the reason they didn't find and correct the problem...
Problem #6: Rubber Keyboard
It didn't hurt the Sinclair ZX Spectrum's sales too much. I'd say the same thing about most PC keyboards sold today but it comes down to money. $6 for a cheap rubbery key keyboard or $75 for a clicky microswitch keyboard.. most people aren't prepared to pay the extra.
There's a huge difference between a rubber membrane keyboard with plastic keycaps and one without... As for the ZX Spectrum - whether the thing was popular or not I wouldn't exactly say people were happy about that keyboard...
Problem #15: Unreliable Proprietary Disk Drives
I'd say all disk drives are proprietary until they become a standard. If the machine had been a success i'm sure everyone would have licensed it.
Back then each platform would usually have its own format for data on the disk, and all of these were incompatible. However, the media itself was generally compatible between platforms. If you had a 5.25" single-density drive, then you went to the store and bought yourself a 5.25" single-density disk and formatted it at home.
The Lisa used a new type of 5.25" disk developed internally at apple - it wasn't compatible with anything. It probably cost Apple a bundle to develop it, and the drives apparently were difficult to produce. All of this could have still worked out - people could have accepted the trade-off of a non-standard disk media in exchange for the increased capacity - except that in the end the drives were unreliable. It doesn't matter how much data a drive holds if it's always at risk of corrupting the data.
And then, if you look at these disks - it seems like they'd be real confusing for users, too. When you're holding a FileWare disk to insert it, you have to hold one of the corners: because the end that's being inserted into the drive and the end facing you both have exposed disk tracks. If somebody grabbed the media as they would a regular 5.25" disk, they'd fingerprint the media.
So the issue there wasn't just that you were stuck with this crappy drive and couldn't swap it out for something else. The issue there was that Apple put a bundle into trying to make a better floppy drive and tied the Lisa platform (and the Mac, too, while it was still under development) to this standard - and they didn't make it work right. The whole thing was a fiasco - a disaster from any reasonable perspective. It probably contributed to the failure of the Lisa and it could have potentially killed the Mac as well.
And to be honest, were those bulky expansions really design mistakes or do they just seem that way now that we have the benefit of a couple of decades of experience and design put into the problems they were meant to address?
Not to mention the fact that they show some ridiculous examples of fully-loaded systems... Everything you could possibly attach to the computer at one time...
It was pretty lame how they listed that one problem ("sidecar modules") three times - and once with a different name...
I'd have a hard time seeing USB coming out back in the era being described, and not just because every company was doing its best to lock people into their own platform.
I'm not sure what your point is here. Even back then there were established standard ways of interfacing with various types of devices: Parallel port for printers, RS-232 for modems... Only disk drives were entirely left to the computer manufacturers' discretion.
And even when computer manufacturers came up with their own interfaces for that stuff (like Commodore's IEC bus for disk drives and printers, and their TTL-level serial port that saved them the cost of a connector and a line-level converter) in most cases the peripherals were still connected by cords - the cited problem with these "sidecar modules" wasn't that they were very model-specific (most hardware was, back then), it's that the whole "sidecar" idea, while convenient, didn't work out so well as the number of modules increased... Had they just made it possible to insert a length of cable somewhere into the chain of devices, the problem would have been pretty much solved.
That makes as much sense as buying a car and then being forced to go out and buy a steering wheel. The car will drive without the steering wheel, but you won't get to where you want to go.
Ohhhh... It all makes sense, now! Thank you for rephrasing the discussion in the context of cars: truly a problem domain which is like second nature to me, and to everyone else I know!
Alphabetical order creates an unfair advantage for products starting with the letter A. They should randomize the order each time the list is displayed.
And to make things simple for the user, they could adopt the following rules for the default selection on the list:
Internet Explorer is always at a random position in the list The default selection on the list is also at a position which was randomly chosen.
And there is no technical reason for there to be a pre-installed browser, as you don't need to have a full browser UI to be able to download a browser to install. A program to download the latest installer over the internet via http or ftp is relatively trivial nowadays.
Actually there are several good reasons to ship a pre-installed browser...
For starters - yeah, it'd be reasonably easy to put an installer on the machine that can, without "browsing the web", get you a web browser. But such a program is a bit of a problem for non-technical reasons: does it just install one particular web browser? Does it give the user a short list of choices? Which choices do and don't make the cut? Is Microsoft seen as "endorsing" or "supporting" these choices if it ships them? (Not really fair to put that burden on them...) Or if it gives the user total freedom to download any browser - then how does the user find that browser? Be sure to consider the problem from the perspective of someone who may not know the FTP URL for the latest version of their favorite browser. (I know I don't...) The common method a user uses for installing a web browser begins with "launch a web browser" - as in "launch a web browser and go to mozilla.com"... Obviously this is a lot easier if there's some kind of web browser already present.
Then you have to consider what else a web browser may be used for: the rendering engine (and possibly the network part as well) may be exposed as program modules for application writers to use. If your API already provides all the core components of your web browser, it's practically nonsensical to not include the GUI front end that turns that into a "web browser application"...
So I'd say my opinion on this whole matter is a bit split - on the one hand I don't like that Microsoft is able to leverage their dominance of the desktop OS market to get loads of people using their defective web browser - but on the other hand I don't entirely agree that they shouldn't be allowed to bundle it, or that they should be required to bundle other browsers that they didn't write and shouldn't be expected to support.
Isn't that more the fault of the dumb bastard than the karma whore?
Perhaps. It's still obnoxious, though.
"Oh, I am the martyr of Slashdot! The one person cursed to be here, while holding a high opinion of Microsoft! I will surely be modded down for this, which will simply be the end of me - but so be it! Let it end, then - let my torment be ended at the hands of the Slashdot collective mind..."
Wah wah wah... So you came to a corner of the internet where people tend to bash Microsoft and you're not someone who's into that. Get over it! Just say things like "I think Microsoft Powershell is pretty neat" or "I think the Common Language Runtime is a really great way to bring different programming languages together" or whatever else positive things you have to say about Microsoft... And don't sweat the reaction from the mythical "collective". You got to be the change you want to see in the world (or in this case, the website) - hopefully the "change you want to see" doesn't include more whining. I know for me it doesn't...
You miss the point. It is commentary on how Slashdot is hugely Anti-MS to the point of being retarded, and how posting anything supporting MS is a nice way to generate some hate.
No, it's like others have said - it's a form of karma whoring... Whine about how you'll be modded down, so you won't be. I don't have a huge problem with karma whoring in and of itself but this is an obnoxious form of it IMO (basically, people whining about the fact that their opinion is not popular here) so I'd like to reiterate the sentiment that these people should just shut the fuck up.
Just make your point, and leave that crap out next time.
Just make your point, and leave out the fucking vulgarity shit next time.
There, I fucking fixed that for you and your god-damned namby-pamby, oversensitized ears.
Slashdot Mirror
Really, all this boils down to is more work for Stephen Fry.
IT is ballooooon!
Pah! Everybody knows that Indy was the dog's name!
Or what's the "old and understood" method for an application to receive notification when the disk is full? Or when a USB device is inserted?
I agree with the above sentence (and I completely agree with the GP, he nailed it on the head). The problem I see with modern distros (modern GNU/Linux) is that many of those features that somebody "needs" are being hacked into the system without really thinking about the big picture. Basically, we're just hacking extra stuff into GNU/Linux that somebody wants to have now, because she saw it in a different OS and it seemed nice.
Could you elaborate upon that? Like what's an example of such a system? Why is it not necessary? Or why does it not fit in with the rest of the system?
I have to admit I'm still not too familiar with a lot of this stuff - for instance I don't know much about hald except that it delivers hotplug notifications and such, and most of what I know about dbus I learned yeaterday after a cursory google search. But from what I know so far it generally seems like good stuff.
So Opera's going to transform and combine to form a giant robot?
Did they just slap a GUI on Emacs?
Don't be ridiculous. Everybody knows Emacs already has its own GUI
I once thought I had Mono for an entire year. Turns out I was just really bored.
It's going into the default Debian desktop install. Don't be a pedant.
You got to bear in mind, I think, that a lot of us may have been running Debian for ages, but may not have actually installed it in several years... I know that prior to last year (when I finally moved to AMD64) I had been on the same Debian install for ages... I don't think they had the "install profiles" back then, it was just "install base system" and then select the other stuff you wanted. Using dselect. :)
> Actually, all of those are very useful,....
No, they might be useful someday. Today they are all semi-stable and almost totally undocumented black boxes that upend forty years of UNIX/POSIX tradition yet were pushed into production in this insane quest to be a better Windows than Windows and thus somehow bring about the Year of Linux on the Desktop.
So while all of the old understood ways of configuring a system have been tossed into the trash, the new replacements aren't ready for prime time. By ready I mean 'just works' at least 99% of the time and has clear documentation to permit a skilled UNIX admin to fix that last 1%.
My perspective:
I appreciate the history and tradition of Unix/Posix but I don't believe any of it is beyond the need for improvement.
For instance, what's the "old and understood" method for writing an application to which another process can connect at runtime and send commands, or receive notifications? SYSV IPC? Binding to some random port number, hoping nobody else is using it, and waiting for connections? Putting a named pipe somewhere on the filesystem and... (you'll have to forgive me, here - I haven't learned quite enough to know all the details of how to implement a thread-safe application object interface via named pipes...)
Or what's the "old and understood" method for an application to receive notification when the disk is full? Or when a USB device is inserted?
I'm with you to a point: that the changes in how things are done in the last several years have been a bit baffling and hard to keep up with at times. But I feel like in general it's been good stuff. Each time the system gets a bit more coherent, a little better suited to what I want it to do...
I think that's a good summary of the anxieties of end users.
"the greater danger is always simply that the package maintainers will simply stop working on the project."
That's something real and within most people's experience. Yet it doesn't stop us happily using all kinds of stuff which may be deprecated/abandoned in a few years.
Well, in my case it does. :) At least it did when I was thinking of getting set up with some iPhoto-like software... F-Spot's the only one I liked enough to keep it installed - but I didn't go to the extent of cataloguing all my old photos or importing new ones. I should really rethink that, one of these days... F-Spot could very well be the one that's worth the time and effort.
Something like a protracted legal dispute ... or a decision by either the FSF or the OSI that mono doesn't meet their definitions of Free or Open Source software. Unless that happens then the people who oppose mono are really wasting their breath.
I wouldn't exactly say they're wasting their breath. They have their own idea of how Linux as a platform should evolve, and to them Mono isn't a part of it. They are advocating (if not in a particularly nice way) their own idea of how things should move forward, and they are having an impact.
The unfortunate bit is that this whole conflict over Mono doesn't get us anywhere. It's progress, in one direction or another, which improves and advances the platform. If Mono were more universally adopted by Linux users, I think that would be a good thing for the platform. For people who want to write commercial applications it represents, among other things, a fairly stable ABI... For the rest of us, it could be a good system infrastructure component - if our culture can accept it.
But there's my dilemma - I feel the Linux platform would benefit from having some more powerful and version-stable components standard - even just from a "hacker" perspective that's valuable. Improving inter-language binding is very valuable, as is providing a generic mechanism applications can use to generate optimized code at runtime. Likewise the potential implications for IPC, application scripting, and so on are all grand. So I believe having a "core component" that does roughly what Mono does would be a great asset. Any candidate that can provide that functionality would be a good thing, and the main criterion that discerns how useful it is would be the adoption rate. So from that perspective, I should stand behind Mono as the prime candidate of a means of providing that functionality - except that I don't like the character of that particular solution, and that matters to me. So it's either embrace something I don't really like to try to promote the benefits it will bring, or don't embrace it, and hope something else that's "more Linuxy" will fill roughly the same role on Linux as .NET does on Windows. But it would take some serious time for all that to happen... like years...
My understanding (I may be wrong and am happy to be corrected) is that the worst that Microsoft could do would be to extend .NET in ways that make projects built on mono incapable of being compatible with .NET.
Really, I don't think anybody would know what Microsoft could do against Mono until/unless they tried... It would be all about how the lawsuit plays out - what's happened so far may not have a great deal of influence upon that.
I don't at all know how likely it is that Microsoft would even try to damage Mono. It seems to me that it all depends on whether they felt they had something to gain from it.
It would be a bigger issue if mono was, like Sun's Java, the basis of important enterprise applications. That doesn't seem to be the case.
It's still fairly new. We may have simply not reached that level of reliance upon it yet. But a tool like Mono - if people aren't relying on it, then it means we're not yet fully taking advantage of it.
Consider the .NET versions of Python and such, for instance: they offer some nice advantages, particularly in terms of integrating Python code and data with code written in other languages. I believe, for instance, that it's quite straightforward to write a Powershell commandlet in IronPython. This is a practical benefit of the .NET platform that Linux doesn't share because of limits in how people are apparently willing to utilize Mono at this point. You won't generally find IronPython on Linux systems, let alone in place of CPython... (Does it even work on Mono? I don't know...)
Gnome and various developers, in house and independent, would have wasted some time and resources. Tomboy is not the only note tool, F-Spot is not the only photo manager and Beagle is not the only meta-search tool.
It's important to look at what that means for those applications now, however: uncertainty about Mono translates to these applications. I know I don't want to invest myself in any photo-management application that I would be unable to rely upon in the future. If I started using F-Spot to manage my photos and then had to stop using it, I don't know where that would leave me in terms of the organization of my photos.
In practical terms, though, I feel like the greater danger is always simply that the package maintainers will simply stop working on the project. That's a risk that exists for any such app, independent of any perceived Microsoft threat.
The one truly effective and practical act that would negate mono would be the development of applications with the same appeal to users and distributions and the Gnome project. Tracker is a reasonable substitute for Beagle. Despite being a fan and a user of Gthumb and Geeqie I wouldn't have the bare-faced cheek to claim they are drop in replacements for F-Spot or even claim to have similar goals or features in many important ways.
Well, it's a lot of work to write an application like that - and for the most part I think it's a waste of time. The motivated developer talent in Linux is spread thinly enough, I think, without having to rewrite perfectly good applications. (Though to a certain extent this is unavoidable - different teams will often take on the same problem and come up with "competing" solutions, each with different advantages - it takes time for any kind of clear winners to emerge...)
You think wrong. Mono is 100% Free Software.
And it's all copyrighted...
Patents are the "worry".
Free software relies on all kinds of sources. The GNU system itself was/is a re-implementation of UNIX. Many of the languages used started off as proprietary. There's nothing new in this. Where is the campaign to purge Fortran or Pascal from the free software opus? Why no campaign against Samba and the use of the SMB protocol? Why is nobody outraged at DotGNU? Where are the calls to cease supporting .avi container and other MS developments?
The difference there, to my mind, is the extent to which we come to rely upon these various technologies. If the Samba project were defeated through legal measures by Microsoft (and please don't interpret this as a suggestion that this will happen - it's just a scenario.) then what would we lose? One LAN file sharing protocol out of many, the ability to share files over a LAN with Windows machines without installing any additional software on the Windows machine...
Mono (or DotGNU, if anybody actually used it) present a somewhat different problem: here you've got something which (IMO anyway) Linux sorely lacks: a coherent VM implementation that can be used in the implementation of different scripting languages, a consistent data representation that can be used to help bind different languages together, and additionally C#, which seems like a good language for application development. This places it in a much more critical position if one comes to rely upon it.
It's hard to debate with people when their fundamental position is composed essentially of hatred, fear and dislike of persons or groups. Where is the factual basis? Where is the ability to consider anything useful when hate or fear is the driving force? This is religion by another name, it cannot be reasoned with, it is impervious to contradictory verifiable fact, it allows no deviation.
There is no contradictory verifiable fact. In the end, Microsoft will either use legal means to defeat Mono, or not. Nothing they say or do now actually prevents this from occurring. Likewise there's not much in the way of "factual basis" apart from what Microsoft has done in the past. You are right that this is largely about fear: though personally I am not entirely convinced that this fear is entirely unfounded. Sometimes there's not a lot of solid information to rely upon: in that case there's no choice but to guess, gamble at what will and won't happen in the future.
Personally, I feel like Mono is not necessarily what I signed on for when I chose to use Linux in the first place. It's a petty reason, really, but even such simple things as putting ".exe" on the end of a filename, or using the same file type signature as DOS executables - these aren't things I really want to see on my system. It gives the programs a bit of an alien character. I don't think it's especially sensible in general for compiled programs to run in a VM, for that matter. Matters of taste like this may seem silly but they are relevant, to my mind: if things don't fit my own idea of what I'd like Linux to be, as a system, then I generally won't be too inclined to stand behind them.
Really, any time you try to introduce some critical piece of infrastructure to the system, people will be hesitant to invest themselves in it - they need to be convinced that it's the right thing. Any facet of the system that people don't like will count against it, and stand in the way of people adopting it. It's not enough for a bit of technology to be good - people have to embrace it or its merits won't make a difference.
It's a tough problem for a platform where there's no central authority - how does one make the platform as a whole advance at a fundamental level, when there's no one to lay down the law about how the core components will work? Groups like Gnome or KDE or major distributions like Debian or Ubuntu are about the closest thing we've got to an "authority" to make these decisions stick - honestly it makes me a bit uneasy that Gnome has gone with
*On another note: What's the point of Gnome again, now that Qt/KDE is open sourced?*
To not be a cluttered piece of crap, which is KDE's job. See on UNIX, every program should do one thing and do it well.
I've always thought KDE's applications were much better than OpenOffice - and Gnome doesn't seem to have any productivity applications at all...
(I've run mostly KDE for a long time, though I have been running Gnome of late, on my new laptop - and I'm quite enjoying it...)
I really strongly feel that Unix lacks the coherent infrastructure needed for this "each tool does one thing well" philosophy... If each tool does just one thing, then your ability to accomplish things strongly depends on how effectively and easily you can link multiple tools together... I feel like the old Unix tools philosophy has gone AWOL of late, and it's pretty much absent from the GUI space, where an individual application is usually written to handle all possible actions for an individual problem domain, and there's very little consideration made to linking these applications together...
IMO however, introducing a cable into the mix really doesn't solve the underlying issue that this purports to be. Now instead of a huge compact piece of equipment, you have a huge sprawling piece of equipment with a spiderweb of cords.
Yeah, been there, done that. That was my computer desk around 18 years ago. And you know, it actually worked out rather well - a lot better than it would have if the devices were all sidecars.
I had a Commodore 128 (itself an indecently large machine) with two drives, printer, modem... If I could've afforded a RAM expansion or hard drive, I would have got one. Pretty much all the same gear they showed hooked up to that TI99-4/A except it didn't have to be all connected together in a straight line... So I had the drives off to the right, set back underneath the bookshelf area of my computer desk, I had the printer off to the side on a printer stand (which also housed the mass of tractor-feed paper), and the modem (I used an RS-232 line-level converted and a standard RS-232 modem at the time) off to the left. And because I didn't have to connect the peripherals directly adjacent to the machine, there was room on the right for me to use a mouse or joystick.
Daisy chaining wasn't a huge problem on the Commodores, either - I suppose it might have been if the cables were parallel links rather than serial - but it would've been rare for a drive to fail so completely that it could no longer communicate with the host - and even if it had, it wouldn't have broken the daisy-chain (the bus was wired straight-through)
So I don't think the bulk of the equipment back then was necessarily a huge problem. You just had to organize it nicely, and it was workable. With sidecars your options for "organizing" would have been very limited.
It baffles me sometimes when people choose to get an external hard drive or CD-writer which is then left permanently plugged in to the machine... I mean, the spider-web of cords is workable, but it's still a hassle. Why would you choose that when you've got a nice cozy internal drive-bay for the thing?
Problem #4: EM Pulse Erases Tapes
Hardly a design mistake. Its more a lack of testing mistake.
No, pretty sure that's a design mistake. The lack of testing is just the reason they didn't find and correct the problem...
Problem #6: Rubber Keyboard
It didn't hurt the Sinclair ZX Spectrum's sales too much. I'd say the same thing about most PC keyboards sold today but it comes down to money. $6 for a cheap rubbery key keyboard or $75 for a clicky microswitch keyboard.. most people aren't prepared to pay the extra.
There's a huge difference between a rubber membrane keyboard with plastic keycaps and one without... As for the ZX Spectrum - whether the thing was popular or not I wouldn't exactly say people were happy about that keyboard...
Problem #15: Unreliable Proprietary Disk Drives
I'd say all disk drives are proprietary until they become a standard. If the machine had been a success i'm sure everyone would have licensed it.
Back then each platform would usually have its own format for data on the disk, and all of these were incompatible. However, the media itself was generally compatible between platforms. If you had a 5.25" single-density drive, then you went to the store and bought yourself a 5.25" single-density disk and formatted it at home.
The Lisa used a new type of 5.25" disk developed internally at apple - it wasn't compatible with anything. It probably cost Apple a bundle to develop it, and the drives apparently were difficult to produce. All of this could have still worked out - people could have accepted the trade-off of a non-standard disk media in exchange for the increased capacity - except that in the end the drives were unreliable. It doesn't matter how much data a drive holds if it's always at risk of corrupting the data.
And then, if you look at these disks - it seems like they'd be real confusing for users, too. When you're holding a FileWare disk to insert it, you have to hold one of the corners: because the end that's being inserted into the drive and the end facing you both have exposed disk tracks. If somebody grabbed the media as they would a regular 5.25" disk, they'd fingerprint the media.
So the issue there wasn't just that you were stuck with this crappy drive and couldn't swap it out for something else. The issue there was that Apple put a bundle into trying to make a better floppy drive and tied the Lisa platform (and the Mac, too, while it was still under development) to this standard - and they didn't make it work right. The whole thing was a fiasco - a disaster from any reasonable perspective. It probably contributed to the failure of the Lisa and it could have potentially killed the Mac as well.
And to be honest, were those bulky expansions really design mistakes or do they just seem that way now that we have the benefit of a couple of decades of experience and design put into the problems they were meant to address?
Not to mention the fact that they show some ridiculous examples of fully-loaded systems... Everything you could possibly attach to the computer at one time...
It was pretty lame how they listed that one problem ("sidecar modules") three times - and once with a different name...
I'd have a hard time seeing USB coming out back in the era being described, and not just because every company was doing its best to lock people into their own platform.
I'm not sure what your point is here. Even back then there were established standard ways of interfacing with various types of devices: Parallel port for printers, RS-232 for modems... Only disk drives were entirely left to the computer manufacturers' discretion.
And even when computer manufacturers came up with their own interfaces for that stuff (like Commodore's IEC bus for disk drives and printers, and their TTL-level serial port that saved them the cost of a connector and a line-level converter) in most cases the peripherals were still connected by cords - the cited problem with these "sidecar modules" wasn't that they were very model-specific (most hardware was, back then), it's that the whole "sidecar" idea, while convenient, didn't work out so well as the number of modules increased... Had they just made it possible to insert a length of cable somewhere into the chain of devices, the problem would have been pretty much solved.
It's a trap!
Your tongues can't repel flavor of that magnitude!
There, I fucking fixed that for you and your god-damned namby-pamby, oversensitized ears.
This is THE only time i have ever seen "namby-pamby" actually written.
Hardly surprising: I mean my spell checked rejected it and everything... :D
That makes as much sense as buying a car and then being forced to go out and buy a steering wheel. The car will drive without the steering wheel, but you won't get to where you want to go.
Ohhhh... It all makes sense, now! Thank you for rephrasing the discussion in the context of cars: truly a problem domain which is like second nature to me, and to everyone else I know!
Alphabetical order creates an unfair advantage for products starting with the letter A. They should randomize the order each time the list is displayed.
And to make things simple for the user, they could adopt the following rules for the default selection on the list:
Internet Explorer is always at a random position in the list
The default selection on the list is also at a position which was randomly chosen.
And there is no technical reason for there to be a pre-installed browser, as you don't need to have a full browser UI to be able to download a browser to install. A program to download the latest installer over the internet via http or ftp is relatively trivial nowadays.
Actually there are several good reasons to ship a pre-installed browser...
For starters - yeah, it'd be reasonably easy to put an installer on the machine that can, without "browsing the web", get you a web browser. But such a program is a bit of a problem for non-technical reasons: does it just install one particular web browser? Does it give the user a short list of choices? Which choices do and don't make the cut? Is Microsoft seen as "endorsing" or "supporting" these choices if it ships them? (Not really fair to put that burden on them...) Or if it gives the user total freedom to download any browser - then how does the user find that browser? Be sure to consider the problem from the perspective of someone who may not know the FTP URL for the latest version of their favorite browser. (I know I don't...) The common method a user uses for installing a web browser begins with "launch a web browser" - as in "launch a web browser and go to mozilla.com"... Obviously this is a lot easier if there's some kind of web browser already present.
Then you have to consider what else a web browser may be used for: the rendering engine (and possibly the network part as well) may be exposed as program modules for application writers to use. If your API already provides all the core components of your web browser, it's practically nonsensical to not include the GUI front end that turns that into a "web browser application"...
So I'd say my opinion on this whole matter is a bit split - on the one hand I don't like that Microsoft is able to leverage their dominance of the desktop OS market to get loads of people using their defective web browser - but on the other hand I don't entirely agree that they shouldn't be allowed to bundle it, or that they should be required to bundle other browsers that they didn't write and shouldn't be expected to support.
Isn't that more the fault of the dumb bastard than the karma whore?
Perhaps. It's still obnoxious, though.
"Oh, I am the martyr of Slashdot! The one person cursed to be here, while holding a high opinion of Microsoft! I will surely be modded down for this, which will simply be the end of me - but so be it! Let it end, then - let my torment be ended at the hands of the Slashdot collective mind..."
Wah wah wah... So you came to a corner of the internet where people tend to bash Microsoft and you're not someone who's into that. Get over it! Just say things like "I think Microsoft Powershell is pretty neat" or "I think the Common Language Runtime is a really great way to bring different programming languages together" or whatever else positive things you have to say about Microsoft... And don't sweat the reaction from the mythical "collective". You got to be the change you want to see in the world (or in this case, the website) - hopefully the "change you want to see" doesn't include more whining. I know for me it doesn't...
You miss the point. It is commentary on how Slashdot is hugely Anti-MS to the point of being retarded, and how posting anything supporting MS is a nice way to generate some hate.
No, it's like others have said - it's a form of karma whoring... Whine about how you'll be modded down, so you won't be. I don't have a huge problem with karma whoring in and of itself but this is an obnoxious form of it IMO (basically, people whining about the fact that their opinion is not popular here) so I'd like to reiterate the sentiment that these people should just shut the fuck up.
Just make your point, and leave out the fucking vulgarity shit next time.
There, I fucking fixed that for you and your god-damned namby-pamby, oversensitized ears.
Restoring old cars saves energy and is environmentally friendly. I bought a used 1992 F250 needing work
No no no no no... I mean old cars...