My experience has been that that can be an issue, but isn't always.
I operate a network of Linux thin clients at work. We use an XFCE4 based desktop for the basic users, and its very much laid out to be idiot proof. The users work comfortably on it, and I know several folks have learned how to do a lot more than they ever did on their Win95 systems. Everything is presented right in front of them, MacOS X dock style, and it's all easy to use.
We're now trialling GNOME based desktops for some of our intermediate users. Initial results with this were abysmal, mostly due to reliablity problems, but a terminal server upgrade to a more modern OS has helped a lot with that. There are still issues, but things are working well enough that it looks promising for the future. These users just don't care what OS they're using, so long as they can manage their files, read PDFs, use a word processor, and deal with their mail.
There also comes a point where "I want windows" simply has to be answered with "Unfortunately, that's not possible - the company has standardised on something else."
In any decent SOE, the user shouldn't be installing toolbars, iTunes, etc etc etc anyway - the difference between a linux-based SOE and a Windows one should be minimal. In fact, the user may have more freedom to install things under the Linux based one (unless you choose to mount homedirs 'noexec').
I just don't see it as that big a deal. Use the appropriate environment for the job, train the users, don't just drop something on them without warning. It should be fine. You'll always have some user resistance to any change, but there are long standing ways of dealing with change resistance that have been needed with many desktop and app migrations before.
What's really hilarous is that the screen shot has telnet in use. Telnet. I can only hope its disabled by default, but even so... I wouldn't choose that as a demo for any OS (Yes, I know connecting to 127.0.0.1 is safe, it's the principle of the thing).
Just a nitpick, but there are LOT more than two kinds of keyboard. The French use AZERTY, for example, and I think many/most countries have their own varyingly different layouts.
Personally, I'd like to see SCGI deployed more widely. Then we could drop the requirement for mod_ for many apps, and make it much easier to deploy frameworks and languages on hosting providers.
I've been really impressed with SCGI for my own work (a Quixote + Python based web app).
I'm on a system similar to that, but informal and a bit sloppier. I simply work "about" 20 hours per week, plus or minus a bit each week. Some of this is at home, some in normal business hours on site, some on site outside business hours (server maintainance, etc). It usually balances out very well.
If I need to a lot more for a while, they even pay me overtime.
Being able to say "I can't be stuffed going to work today and there's nothing critical on. I'm going sailing." is worth a lot to me.
If you have management that will actually allow you to do this, then it's real simple. The project manager will take projected timelines for your required projects, and add 20%. If you work efficiently,... you actually get the project out the door on time, for once.
If you have the miracle that is a realistic, sensible, and competent project manager - not a PHB from middle management - then I suspect you're rather lucky.
I'm my own project manager, so I don't find this to be an issue myself - my project manager is a jerk and an idiot, but never fails to allow reasonable time for a project.
I'm working for a business where I'm able to spend a considerable amount of time working on personal projects. In my case this is because my project happens to be working on things that may prove useful for solving problems within the business later. I win, they win.
It'd be nice, but as explained in the article wouldn't solve the whole problem. You still have event model integration, you still have the nightmares that are fonts and printing, etc.
That's a very good point. One certainly does have to jump through more than a few hoops to get sensible sizes, deal with endianness and word size issues, etc.
Very ugly hoops.
I should've said that it is possible to write portable apps in C, and that an app written with portability in mind shouldn't be too painful to port to a new platform. This is especially true if you make a point of testing on, say, a big-endian 64 bit PPC machine.
I don't think the JVM supports such things directly. If it does, I'll be very impressed, since it certainly didn't have anything like that when I was last using Java for my own code (admittedly in the we're-still-using-AWT days).
Java does provide the ability to build extensions, so there's no reason you couldn't provide extensions to do these things. Ideally you'd write a platform neutral API and then implement it for each platform you ran on, so your Java code didn't have to care about what platform it was on. For some stuff, of course, this just won't work and you'll have to handle each platform differently or port some of your java files for each platform.
It may well be worth looking into third party tools to do some of this. For example, I'd be very surprised if OLE wasn't availible either built-in with the JVM, or as a 3rd party add-on.
You may run into more trouble with things like making "feel" like apps for your platform. SWT is probably worth looking into for this, and may be what you're after when it comes to Java GUIs.
In the end, this is part of my gripe about java - while its cross platform, it doesn't really fit in well on any platform.
I can't seem to run it - I may not have the JVM installed on my laptop. No big deal.
The only other toolkit I know of that can do that is Qt, and even then I think you have to jump through a few hoops. That's a pretty nice table widget.
Individual bits of Swing are pretty good, and I think a lot of the API is nice, with a good collection of widgets (if often rather verbose). It's just that the few non-trivial Swing apps I've used have been very sluggish, and really haven't fitted in with the rest of the OS's widget set. "Java 5" - jvm 1.5 - helps a lot with looks, but at least on *nix Swing is still very much the in the distinctive knobbly sun style. I don't know if they've made a big and much needed performance improvement for Swing in 1.5 too - I no longer use any Swing-based apps regularly, having found better alternatives.
I'd be very interested in seeing a non-trivial app written in Swing that had a UI as snappy and responsive as one written in, say, Qt.
Many others have mentioned GCJ, and that's all fine. Personally, I'm not convinced compiling to native code is necessary a lot of the time. The JVM is awfully fast for most tasks already (though RAM consumption can be an issue).
My (admittedly limited) experience has been that most of the performance issues with Java have been with Swing. I'd be interested in seeing how that was affected by native compilation, but I'm not aware of any project that can do that yet. A native _implementation_ of Swing for a platform would interest me more.
I personally feel that while in an ideal world Java would be good solution, I'm not convinced its the answer to all the world's software portability problems.
ANSI C is very portable. It's also utterly useless for things like GUI applications, unless you feel that writing your own GUI toolkit and low-level system interface is fun. Portability problems are introduced by the system APIs and GUI toolkits used to do interesting things - not by the language.
Java provides a standard GUI toolkit, plus some very good abstractions of platform APIs. If, however, you want to go beyond those platform APIs, you're back at square 1 - re-implementing the platform service, or writing an interface to it to abstract it for cross platform use. Bang! Your Java app just ceased to be portable.
To get the sort of OS integration the mac users rant about, I'd be very surprised if you didn't have to write a few extensions for platform API interfaces.
Another issue with Java is the GUI toolkit. IMO Swing is clunky, ugly, and gives everybody the SAME poor "user experience". Even tools like JEdit that I've seen held up as examples of how well things can work feel pretty painful in my experience when compared to a native app. I'd find Java a lot more interesting if Sun would bite the bullet and put their weight behind SWT.
In the mean time, I'll be sticking to C++ and Qt - IMO the next best thing for portability, and much better when it comes to GUI work. Of course, Qt borrows liberally from the Java APIs where they're good, and I'll for that.
As for Mozilla, I'm pretty sure they implement their own GUI toolkit - not a window system. I'm with you on the slow RAM hog, though.
I'm not one to argue that Java is fast, but IMO until they Sun addresses the Swing albatross Java won't be a viable first choice for implementing serious GUI applications where "user experience" is a major concern.
Most of the magic is in Qt
on
KDE 3.4 goes Beta
·
· Score: 2, Interesting
The really impressive translation magic is in Qt's i18n tools ( QObject::tr(), lupdate, lrelease, etc). It "just works" - you code your app in English, but mark strings as translatable and translators can translate your app using external files generated from the source that can be distributed separately.
It's fantastic.
Sure, there's more work involved in making external resources like HTML help translatable, but the real magic happens in Qt.
Qt4 is a really major change. It is most definitely non-trivial to port code to Qt4, even with the Qt3 compatiblity libraries.
As someone facing the need to port their code to Qt4 sometime in the coming year, I'm all too aware of this.
I wouldn't expect a Qt4 based KDE in any hurry. Even if they're already porting to the Qt4 beta, I expect it'll take them a fair darn while even after Qt4 stable comes out before they can put together a Qt4 desktop. Even then, I'll be surprised if some apps don't continue to use Qt3 for a while after that.
Dude, NASA are sending out space probes. Each one is new, different, and complex. They travel utterly incomprehensible distances and deal with really difficult environments. I'm usually astonished whenever one works.
Then there's the small matter of the mars rovers, which both worked beyond all possible expectations.
NASA have had their fair share of screw-ups, but I think if there's anything to take them to task about its their beaurocracy and the amount it costs them to do things, rather than their success rate. I'd like to see them able to lob off far more probes for less money, even if a few more failed, but that doesn't seem to be how they work.
Note that I'm no NASA fanboy, just trying to be a little realistic here.
From TFA: "Using a lost-sales calculus, which measures the losses to foreign companies by determining the value of the dubious goods sold..."
In other words, <i>making the assumption that each sale of a pirated item at a vastly lower price would have been a sale of the real work at its retail price had the pirated work not been availible...<i>.
It's the same old dumb BS all over. This method of estimation <i>is</i> useful as a way of estimating and reporting the magnitude of piracy, but does <i>not</i> mean that had the pirated work not been aviailible the industry would have actually made $amount more money in sales. They may have made $smalleramount more sales, or they may have even made LESS due to reduced word-of-mouth publicity and upgrades from pirated copies (ie for the games industry, "I like this game and want to play it online now"). They would <i>not</i> have made $amount more in sales because the pirated copies are cheaper - ref the very basics of economics. Even had the pirated copies been the same price, chances are they would've sometimes sold in places the originals weren't availible, hence not representing a true lost sale.
Understanding the statistics doesn't make the piracy problem go away, it just means you have a more realistic view of its impact. That's not US$80*(10**9) the US didn't get because of piracy in China, that's all.
I'm sure you knew all this, but it doesn't help to point it out for the totally-ignorant-of-basic-stats.
As for construction quality... those were big controlled bombs designed to launch objects into space. Not ornaments. Their job was to get a payload into space without destroying it or killing anybody, not to sit on the grass looking pretty.
I do take your point about the preservation of historical objects, though. OTOH, they're stepping up to it now... and diverting funds that could be used to do/new/ interesting things, I might add.
Granted, that's not always practical. As someone who has to admin and backup a system with a 1.25TB RAID array, I know that all too well. SDLT? Daily SATA hard disk snapshots? Even/reading/ that much data takes forever.
My solution - periodic off-site hard disk backups plus DDS-4 dailies. If I can go to LTO dailies soon, I'll be happy.
When I/do/ need a rescue CD, usually (but, alas, not always) to make systems bootable rather than to recover data, I tend to use SystemRescueCD.
Your comment regarding road deaths is entirely appropriate, and in fact an argument I tend to use myself in other contexts (such as when people whine about "oh, the terrorists!" or the "terrible danger" of flying.).
In other words, good point.
I guess my point was merely that the war has become surprisingly big and is having an impact on the US, at least as I see it from an outside perspective, that looks quite significant. I've heard comments from folks over there to the effect of "it's no longer just 'some other bugger', it's the guy you/know/ getting his face shot off."
As for killing people, in fairness the US is mostly only killing people who disagree with them by shooting them and blowing them up, not just those that dissent. The number of people getting killed on the sidelines over in Iraq is scary though... when bombing buildings and fighting for control of cities, a lot of folks are going to get killed who were just in the wrong place.
I am worried by the way the US does seem to be getting well into torturing people who disagree with them or were just in the wrong place at the wrong time, though.
For the record, I'm Australian, so my country is following along with what the US is doing like a puppy. I can hardly stand aside and claim it's not my fault or my problem (much as I wish our PM had not taken the side he did).
On a more serious note, the proportion of the US population that must've been affected by this war by now is scary. I wonder when it'll end - will we get Vietnam 2.0, or will they manage to resolve things (hopefully NOT by killing everybody who disagrees with them) before it gets to that?
I wasn't aware of that ; thanks for the info. Of course, the rest stands - zlib, for example, is used in Office . Come to think of it, I'm pretty sure they use libpng as well.
I'm afraid I have to disagree regarding the issue of MS and open source. They're very fond of open source, and have used open source code in many of their products. Mosaic, zlib, and the BSD TCP/IP stack come to mind.
They don't like the GPL and other free software licenses, though, because they can't take without returning anything to the community.
They're also not as happy when open source or free software start getting big enough to be more than a source of technology and code for their own products.
Slashdot Mirror
That's reasonable, though it *will* make life easier for someone who's already breached the network perimeter.
I wouldn't choose telnet as an example for anything though, and frankly would hope it's disabled by default in any modern OS.
My experience has been that that can be an issue, but isn't always.
I operate a network of Linux thin clients at work. We use an XFCE4 based desktop for the basic users, and its very much laid out to be idiot proof. The users work comfortably on it, and I know several folks have learned how to do a lot more than they ever did on their Win95 systems. Everything is presented right in front of them, MacOS X dock style, and it's all easy to use.
We're now trialling GNOME based desktops for some of our intermediate users. Initial results with this were abysmal, mostly due to reliablity problems, but a terminal server upgrade to a more modern OS has helped a lot with that. There are still issues, but things are working well enough that it looks promising for the future. These users just don't care what OS they're using, so long as they can manage their files, read PDFs, use a word processor, and deal with their mail.
There also comes a point where "I want windows" simply has to be answered with "Unfortunately, that's not possible - the company has standardised on something else."
In any decent SOE, the user shouldn't be installing toolbars, iTunes, etc etc etc anyway - the difference between a linux-based SOE and a Windows one should be minimal. In fact, the user may have more freedom to install things under the Linux based one (unless you choose to mount homedirs 'noexec').
I just don't see it as that big a deal. Use the appropriate environment for the job, train the users, don't just drop something on them without warning. It should be fine. You'll always have some user resistance to any change, but there are long standing ways of dealing with change resistance that have been needed with many desktop and app migrations before.
What's really hilarous is that the screen shot has telnet in use. Telnet. I can only hope its disabled by default, but even so ... I wouldn't choose that as a demo for any OS (Yes, I know connecting to 127.0.0.1 is safe, it's the principle of the thing).
Separately to that, looks interesting.
Just a nitpick, but there are LOT more than two kinds of keyboard. The French use AZERTY, for example, and I think many/most countries have their own varyingly different layouts.
Personally, I'd like to see SCGI deployed more widely. Then we could drop the requirement for mod_ for many apps, and make it much easier to deploy frameworks and languages on hosting providers.
I've been really impressed with SCGI for my own work (a Quixote + Python based web app).
I'm on a system similar to that, but informal and a bit sloppier. I simply work "about" 20 hours per week, plus or minus a bit each week. Some of this is at home, some in normal business hours on site, some on site outside business hours (server maintainance, etc). It usually balances out very well.
If I need to a lot more for a while, they even pay me overtime.
Being able to say "I can't be stuffed going to work today and there's nothing critical on. I'm going sailing." is worth a lot to me.
If you have management that will actually allow you to do this, then it's real simple. The project manager will take projected timelines for your required projects, and add 20%. If you work efficiently, ... you actually get the project out the door on time, for once.
If you have the miracle that is a realistic, sensible, and competent project manager - not a PHB from middle management - then I suspect you're rather lucky.
I'm my own project manager, so I don't find this to be an issue myself - my project manager is a jerk and an idiot, but never fails to allow reasonable time for a project.
I'm working for a business where I'm able to spend a considerable amount of time working on personal projects. In my case this is because my project happens to be working on things that may prove useful for solving problems within the business later. I win, they win.
It'd be nice, but as explained in the article wouldn't solve the whole problem. You still have event model integration, you still have the nightmares that are fonts and printing, etc.
It'd still be nice, though.
That's a very good point. One certainly does have to jump through more than a few hoops to get sensible sizes, deal with endianness and word size issues, etc.
Very ugly hoops.
I should've said that it is possible to write portable apps in C, and that an app written with portability in mind shouldn't be too painful to port to a new platform. This is especially true if you make a point of testing on, say, a big-endian 64 bit PPC machine.
I don't think the JVM supports such things directly. If it does, I'll be very impressed, since it certainly didn't have anything like that when I was last using Java for my own code (admittedly in the we're-still-using-AWT days).
Java does provide the ability to build extensions, so there's no reason you couldn't provide extensions to do these things. Ideally you'd write a platform neutral API and then implement it for each platform you ran on, so your Java code didn't have to care about what platform it was on. For some stuff, of course, this just won't work and you'll have to handle each platform differently or port some of your java files for each platform.
It may well be worth looking into third party tools to do some of this. For example, I'd be very surprised if OLE wasn't availible either built-in with the JVM, or as a 3rd party add-on.
You may run into more trouble with things like making "feel" like apps for your platform. SWT is probably worth looking into for this, and may be what you're after when it comes to Java GUIs.
In the end, this is part of my gripe about java - while its cross platform, it doesn't really fit in well on any platform.
I can't seem to run it - I may not have the JVM installed on my laptop. No big deal.
The only other toolkit I know of that can do that is Qt, and even then I think you have to jump through a few hoops. That's a pretty nice table widget.
Individual bits of Swing are pretty good, and I think a lot of the API is nice, with a good collection of widgets (if often rather verbose). It's just that the few non-trivial Swing apps I've used have been very sluggish, and really haven't fitted in with the rest of the OS's widget set. "Java 5" - jvm 1.5 - helps a lot with looks, but at least on *nix Swing is still very much the in the distinctive knobbly sun style. I don't know if they've made a big and much needed performance improvement for Swing in 1.5 too - I no longer use any Swing-based apps regularly, having found better alternatives.
I'd be very interested in seeing a non-trivial app written in Swing that had a UI as snappy and responsive as one written in, say, Qt.
Many others have mentioned GCJ, and that's all fine. Personally, I'm not convinced compiling to native code is necessary a lot of the time. The JVM is awfully fast for most tasks already (though RAM consumption can be an issue).
My (admittedly limited) experience has been that most of the performance issues with Java have been with Swing. I'd be interested in seeing how that was affected by native compilation, but I'm not aware of any project that can do that yet. A native _implementation_ of Swing for a platform would interest me more.
I personally feel that while in an ideal world Java would be good solution, I'm not convinced its the answer to all the world's software portability problems.
ANSI C is very portable. It's also utterly useless for things like GUI applications, unless you feel that writing your own GUI toolkit and low-level system interface is fun. Portability problems are introduced by the system APIs and GUI toolkits used to do interesting things - not by the language.
Java provides a standard GUI toolkit, plus some very good abstractions of platform APIs. If, however, you want to go beyond those platform APIs, you're back at square 1 - re-implementing the platform service, or writing an interface to it to abstract it for cross platform use. Bang! Your Java app just ceased to be portable.
To get the sort of OS integration the mac users rant about, I'd be very surprised if you didn't have to write a few extensions for platform API interfaces.
Another issue with Java is the GUI toolkit. IMO Swing is clunky, ugly, and gives everybody the SAME poor "user experience". Even tools like JEdit that I've seen held up as examples of how well things can work feel pretty painful in my experience when compared to a native app. I'd find Java a lot more interesting if Sun would bite the bullet and put their weight behind SWT.
In the mean time, I'll be sticking to C++ and Qt - IMO the next best thing for portability, and much better when it comes to GUI work. Of course, Qt borrows liberally from the Java APIs where they're good, and I'll for that.
As for Mozilla, I'm pretty sure they implement their own GUI toolkit - not a window system. I'm with you on the slow RAM hog, though.
I'm not one to argue that Java is fast, but IMO until they Sun addresses the Swing albatross Java won't be a viable first choice for implementing serious GUI applications where "user experience" is a major concern.
The really impressive translation magic is in Qt's i18n tools ( QObject::tr(), lupdate, lrelease, etc). It "just works" - you code your app in English, but mark strings as translatable and translators can translate your app using external files generated from the source that can be distributed separately.
It's fantastic.
Sure, there's more work involved in making external resources like HTML help translatable, but the real magic happens in Qt.
Qt4 is a really major change. It is most definitely non-trivial to port code to Qt4, even with the Qt3 compatiblity libraries.
As someone facing the need to port their code to Qt4 sometime in the coming year, I'm all too aware of this.
I wouldn't expect a Qt4 based KDE in any hurry. Even if they're already porting to the Qt4 beta, I expect it'll take them a fair darn while even after Qt4 stable comes out before they can put together a Qt4 desktop. Even then, I'll be surprised if some apps don't continue to use Qt3 for a while after that.
Dude, NASA are sending out space probes. Each one is new, different, and complex. They travel utterly incomprehensible distances and deal with really difficult environments. I'm usually astonished whenever one works.
Then there's the small matter of the mars rovers, which both worked beyond all possible expectations.
NASA have had their fair share of screw-ups, but I think if there's anything to take them to task about its their beaurocracy and the amount it costs them to do things, rather than their success rate. I'd like to see them able to lob off far more probes for less money, even if a few more failed, but that doesn't seem to be how they work.
Note that I'm no NASA fanboy, just trying to be a little realistic here.
Or, say, the totally-ignorant-of-the-goddamm-plaintext-button. Arrggh.
From TFA: "Using a lost-sales calculus, which measures the losses to foreign companies by determining the value of the dubious goods sold..."
In other words, <i>making the assumption that each sale of a pirated item at a vastly lower price would have been a sale of the real work at its retail price had the pirated work not been availible...<i>.
It's the same old dumb BS all over. This method of estimation <i>is</i> useful as a way of estimating and reporting the magnitude of piracy, but does <i>not</i> mean that had the pirated work not been aviailible the industry would have actually made $amount more money in sales. They may have made $smalleramount more sales, or they may have even made LESS due to reduced word-of-mouth publicity and upgrades from pirated copies (ie for the games industry, "I like this game and want to play it online now"). They would <i>not</i> have made $amount more in sales because the pirated copies are cheaper - ref the very basics of economics. Even had the pirated copies been the same price, chances are they would've sometimes sold in places the originals weren't availible, hence not representing a true lost sale.
Understanding the statistics doesn't make the piracy problem go away, it just means you have a more realistic view of its impact. That's not US$80*(10**9) the US didn't get because of piracy in China, that's all.
I'm sure you knew all this, but it doesn't help to point it out for the totally-ignorant-of-basic-stats.
As for construction quality ... those were big controlled bombs designed to launch objects into space. Not ornaments. Their job was to get a payload into space without destroying it or killing anybody, not to sit on the grass looking pretty.
/new/ interesting things, I might add.
I do take your point about the preservation of historical objects, though. OTOH, they're stepping up to it now... and diverting funds that could be used to do
... is a CD labeled "backup 2005-01-11".
/reading/ that much data takes forever.
/do/ need a rescue CD, usually (but, alas, not always) to make systems bootable rather than to recover data, I tend to use SystemRescueCD.
Granted, that's not always practical. As someone who has to admin and backup a system with a 1.25TB RAID array, I know that all too well. SDLT? Daily SATA hard disk snapshots? Even
My solution - periodic off-site hard disk backups plus DDS-4 dailies. If I can go to LTO dailies soon, I'll be happy.
When I
Your comment regarding road deaths is entirely appropriate, and in fact an argument I tend to use myself in other contexts (such as when people whine about "oh, the terrorists!" or the "terrible danger" of flying.).
/know/ getting his face shot off."
In other words, good point.
I guess my point was merely that the war has become surprisingly big and is having an impact on the US, at least as I see it from an outside perspective, that looks quite significant. I've heard comments from folks over there to the effect of "it's no longer just 'some other bugger', it's the guy you
As for killing people, in fairness the US is mostly only killing people who disagree with them by shooting them and blowing them up, not just those that dissent. The number of people getting killed on the sidelines over in Iraq is scary though... when bombing buildings and fighting for control of cities, a lot of folks are going to get killed who were just in the wrong place.
I am worried by the way the US does seem to be getting well into torturing people who disagree with them or were just in the wrong place at the wrong time, though.
For the record, I'm Australian, so my country is following along with what the US is doing like a puppy. I can hardly stand aside and claim it's not my fault or my problem (much as I wish our PM had not taken the side he did).
Anybody else thinking "starship troopers" here?
On a more serious note, the proportion of the US population that must've been affected by this war by now is scary. I wonder when it'll end - will we get Vietnam 2.0, or will they manage to resolve things (hopefully NOT by killing everybody who disagrees with them) before it gets to that?
I wasn't aware of that ; thanks for the info. Of course, the rest stands - zlib, for example, is used in Office . Come to think of it, I'm pretty sure they use libpng as well.
I'm afraid I have to disagree regarding the issue of MS and open source. They're very fond of open source, and have used open source code in many of their products. Mosaic, zlib, and the BSD TCP/IP stack come to mind.
They don't like the GPL and other free software licenses, though, because they can't take without returning anything to the community.
They're also not as happy when open source or free software start getting big enough to be more than a source of technology and code for their own products.
Speaking of britney spears (no, not a gem, the site is):
http://www.google.com/jobs/britney.html