The desktop is always going to matter. Even if we get to a point where there's clouds everywhere (which personally I doubt is going to work they way people are hyping it right now, but that's a whole other debate), the desktop is going to be how you interface with all of them.
The problem really is his other statement. Many desktop linux users are switching to mac. Why is that? Perhaps the Linux desktop just isn't quite there yet. And while I love Linux and the community, frankly the desktop choices still rather suck. They've come a long way, to be sure. But KDE's big problem has always been it's hodgpodginess. GNOME was my best hope back in GNOME 1.0... It was actually really nice to use. But they made a policy decision that they shouldn't have. They removed all choice of configurability. Now it's become this bastard clone of Windows that only really copies the sucky parts of Windows. (albiet with much better fonts than we had before all this started!)
What they should have done is said yes, some people think there's too much customization and no one can really agree on exactly what "THE" way of doing things is. Okay, let's have a policy editor/manager that then lets distribution authors and site administers determine the policy of their systems and configure things the way they expect their users to use them. eg. I'm catering to dumb users that expect things to be like Windows, so I'm going to customize it that way; or I'm catering to uber-geeks that like to have every single option available to them.
As for making money on desktop linux, part of the issue is commercial applications. Identify what the pain points are and see how to resolve it. One of the big issues for commercial developers is the proliferation of distributions. Because of the GPL, it makes it difficult for an application developer to link to GPL'd libraries and expect to work on any distribution (due to a number of reasons: library versions, paths, etc.). In the old commercial Unix days, it was easy, they'd just include a statically compiled version of the app. Unfortunately due to the GPL (and even LGPL) that isn't practical for companies.
So while Redhat I'm sure would only really care about people writing software for Redhat's Desktop Linux. Commercial authors want to make sure they can run an as much Linux as possible. Before that happens, I think we'll continue to see extremely slow adoption by commercial vendors.
That being said, personally, I'm quite happy with most of the OSS out there. But keep in mind commercial needs differ. And sometimes you just have to have commercial software. With April coming around, TurboTax is a good example. (OSS is great, but I don't think anyone's going to be interested in writing an OSS tax software, and I'm not sure how much I'd trust 0.64bpre33 of YetAnotherTaxSuite =) ).
While I can certainly see the usefulness of people using this with voice commands, I'm not sure this is a generally usable feature. Hopefully the distros keep the extension as a separate download.
Does anyone remember Lotus HAL? They tried to do the exact same thing for spreadsheets. And while it had quite a bit of novelty (probably even useful given the insane menu tree of Lotus), I'm not sure it really did all that well. And many others have tried NLP (natural language processing) controlled apps in the 80's. But they were always more confusing to use than the (now) standard menu layouts.
Having said that, I recently was playing with a Mac, and I really like their approach. They have a little "find" sort of entry field that will just highlight or point you to the right help entries with whatever you type. Personally, I think that would be a better way to incorporate NLP.
Actually, this makes perfect sense to me. Java's real problem is that the VM is tied to the language (Java people would disagree with me, but I challenge you to show me a Java Applet written in C).
I want a web-based VM/OS that really is just that, an OS (ala Inferno/Plan9). Let me as a programmer decide what language I want to write the thing in. Python, Java, C, C++, Intercal, whatever.
Java, C#/Mono, etc... all suffer from this problem. (Well that's not exactly true,.Net is probably the closest in offering a real VM OS... but they really don't talk about languages outside of C# and VB).
Now I'm not sure x86 is the "best" platform to use as your "platform independent architecture." Though it is definitely one of the most prevalent and well supported architectures out there.
The upshot of all this, though, is that we can get Linux running in a web browser (I'm sure someone will figure out some cleaver caching), which will *finally* get us all of our Gnome/KDE/Xaw tools available to larger audiences.
This means *finally* a write once, run anywhere world.
And it means we've just turned all web application developers into Linux developers.
The problem I have with MSWord style version tracking is that it's a bit incongruent with my software version tracking. What I'd like to see is a way for OOo to have maybe some type of plugin support for third party version tracking, so that I can tie into subversion for example. Then all we need is a generic OOo diff'ing mechanism and we're done.
ie. I'd like to be able to do a diff between two documents and see things in a similar fashion to the unix diff command. This is something I can't easily do with MSWord documents either, although the way I see most people save multiple copies of their documents, it'd probably be invaluable. (Though I believe there are 3rd party apps for MSWord to do that).
Granted, I do understand that storing editing changes within the document itself is perhaps solving a different problem and has it's own uses.
Unfortunately, in some cases, UI responsiveness directly affects actual performance.
I was surprised to discover one day that running builds with lots of compiler output in a gnome-terminal (I believe KDE's terminal was the same) was significantly slower than running it in a text console. (Actually it was a Windows friend who was pointing out one of the deficiencies in Linux, but that's another story).
Anyway, turns out xterm is still probably one of the best X terminal programs out there, especially in terms of performance. I think one of the ways it's able to get this speed is with something it calls "jump scroll". Though if I recall correctly, even with jump scroll off xterm outperformed many of the other terminals.
What I think is happening in the other terminals is that they're actually causing the main application to block as their writing to the screen. If that's the case... well it's very dumb. Sorry I don't have actual performance numbers anymore... it's been a while since I've looked at it. In fact it was probably around the FC2 or FC3 days, so who knows maybe it's been fixed since then?
When I was considering IM solutions for my company, I was looking into SILC, as that lets me run my own servers in addition to keeping traffic encrypted. I know that wasn't part of your original question. But it may be something you want to look into. Pidgin apparently has SILC client support built-in as well.
In fact hardware RAID is _only_ really useful for throughput. If you care about data integrity during a failure, RAID is really bad (even when mirroring). The reason is because RAID doesn't specify how the data is actually stored on the disk. If you're using a hardware RAID controller and your controller dies, you've lost all your data. You don't always even have the option of buying a new controller, as firmware can change even with the same model.
It's for this reason that I only trust software RAID (linux in particular, of course), whenever I do use RAID. I know I can always take the disk and load it up on another Linux machine without difficulty. The same can't be said for any hardware RAID format. (please correct me if I'm wrong).
It's not specifically JavaScript that's the problem. The problem is thinking that one language will solve all application requirements.
What we need is a way to write applications for this (web) platform with any language you want/need... just like the desktop.
Ideally we'd first have a VM of sorts on the browser... Separate the language from the execution. This would allow people to use their language of choice, and to take advantage of existing languages in order to write web-based display applications. For example, if you look at all the display methods right now: JavaScript, Flash, Java applets, etc. They all have pros and cons to their underlying technologies and browser tie-ins, but they're all tied to the specific language... I may like Java's concept of having a VM/byte-code interpreter, but I'm stuck with doing everything in Java. For some tasks, that just may not be ideal.
Once you've got that separation, then you can do some interesting things and actually learn past lessons. This whole concept of networked computing, remote displays, and server-oriented applications is actually quite old. The primary thing that's changed in the past 20 years is that we have smarter terminals.
So the next step is to develop something like X11 (or perhaps just extend X11?), but take advantage of the fact that we have smart terminals. Allow for the widgets and toolkit stuff (eg. gtk, Qt, etc.) to be loadable onto the remote display. This would provide the benefit that we want... low network overhead and high user interactivity for applications.
This would also allow us to standardize on UI toolkits much more so than we do now with AJAX, et. al. But because the UI can now be standardized, they can also be cached. Once you download a toolkit, you don't need to download it again.
But at the same time if some developers don't like the toolkit, you could easily have others without having to re-write your entire infrastructure. (Think Xaw, Motif, GTK, Qt. If you think that's too many, try to count the number of display toolkits commonly used in today's web application space).
The other benefit this gives you is the ability to just write applications once. You'd actually be able to share code bases when trying to support applications on the desktop and on the web. And this would be no more work than supporting, say Windows and Mac.
So the mistake we actually have has developers (in my view) is not recognizing that the web is a platform just like any other platform. And that we should treat it as such.
I'm not sure that's an either/or there. With a tripod that high, you'd may still have similar stabalization issues. Even assuming a perfectly rigid structure unaffected by the wind, you may have vibrations from the ground. Anyone still in school care to do the calculations?
I'm doing non-realtime embedded work it my current company and my previous one. And I can say that we definitely would like strong C and networking skills, with some hardware familiarity. Some ability to comprehend other discipilines like SQL, PHP, HTML, etc. are also starting to be important in this field as everything's starting to incorporate web pages and web-based configuration.
But even discounting the higher level languages, we've had a horrible time finding anyone with anywhere near the skills we'd need. And we're in Irvine, CA... theoretically one of the tech centers in SoCal.
I'd actually think this field would be growing _because_ the harddware costs are getting lower, and it's becoming easier to just put Linux on everything.
They might be thinking that a jamming signal is typically directional based on where you know the receiver is. I don't know if that's true or not, but that would make sense if you're thinking a stealth antenna avoids jamming.
Any company that can make a mobile phone with no buttons, no picture messaging, slow Web access and no video capture into the most desirable phone on the planet can easily make tablets popular.
Apple's insight there was really just how useless those features are. I'm not saying people won't take advantage of them if they're there, but I'm not convinced it really ads much to the "phone experience." And generally I think it's just too costly to use anyway.
Most phone makers/carriers have lost sight of the primary purpose of the phone: to communicate with people, ideally as easy as possible. While cameras and mp3 playing is neat, and could add some coolness to an otherwise boring phone, you can't skimp on good sound quality, noise reduction, etc. I can't personally say that the iPhone is good on any of those fronts either. I've yet to see a cell phone that's a good basic communication device first.
As an example, go out to your local cell provider and see just how many phones have cameras with buttons on the side that you can't lock! Or try to find a phone that actually mentions its audio input/output response.
But if Apple is able to address even a handful of these sorts of problems, it's no wonder they'd be popular... they'd have no competition! I mean sheesh one of the primary things that would make me switch over is simply the ability to save my voicemail onto my computer!
My initial reaction to the iPhone was the same. I like having buttons and being able to use my devices without looking at them. But then I realized that the cell phone industry has been making things worse and worse over the years. I simply can't operate my own phone without looking at it because of all the "ergo" and fancy styling they do with the buttons. On top of that, no one really remembers phone numbers anymore. I have to look at the phone to dial anyway (though I suppose I/could/ learn how to add a speed dial number).
On top of that, many phones have side buttons that simply cannot be locked/disabled. I know many people who keep their phones in their pockets/purses who just get the phones in weird modes or take thousands of snapshots and lose battery life because of this.
I will admit, though, that I do find the side volume control buttons very convenient. (Incidentally, I spent a good deal of time finding a phone that did still have a lockout mode that worked for the side buttons.)
This is a full OS as a web plugin. Quite small and fast. If you want to "web-icize" linux, I'd suggest making a port of the linux kernel to a mozilla plugin, then write a console/X11 driver, and you're set. Now we can take advantage of all Linux tools in a browser, and we might finally have something better than all this Java / AJAX nonsense.
Slashdot Mirror
Dude, just turn on the quantum instability compensators.
And it'll help sell tee-shirts. Lets face it. those old quantum "I heart strange entanglement" tees were really lame!
ooh.. where can I get one?
The desktop is always going to matter. Even if we get to a point where there's clouds everywhere (which personally I doubt is going to work they way people are hyping it right now, but that's a whole other debate), the desktop is going to be how you interface with all of them.
The problem really is his other statement. Many desktop linux users are switching to mac. Why is that? Perhaps the Linux desktop just isn't quite there yet. And while I love Linux and the community, frankly the desktop choices still rather suck. They've come a long way, to be sure. But KDE's big problem has always been it's hodgpodginess. GNOME was my best hope back in GNOME 1.0... It was actually really nice to use. But they made a policy decision that they shouldn't have. They removed all choice of configurability. Now it's become this bastard clone of Windows that only really copies the sucky parts of Windows. (albiet with much better fonts than we had before all this started!)
What they should have done is said yes, some people think there's too much customization and no one can really agree on exactly what "THE" way of doing things is. Okay, let's have a policy editor/manager that then lets distribution authors and site administers determine the policy of their systems and configure things the way they expect their users to use them. eg. I'm catering to dumb users that expect things to be like Windows, so I'm going to customize it that way; or I'm catering to uber-geeks that like to have every single option available to them.
As for making money on desktop linux, part of the issue is commercial applications. Identify what the pain points are and see how to resolve it. One of the big issues for commercial developers is the proliferation of distributions. Because of the GPL, it makes it difficult for an application developer to link to GPL'd libraries and expect to work on any distribution (due to a number of reasons: library versions, paths, etc.). In the old commercial Unix days, it was easy, they'd just include a statically compiled version of the app. Unfortunately due to the GPL (and even LGPL) that isn't practical for companies.
So while Redhat I'm sure would only really care about people writing software for Redhat's Desktop Linux. Commercial authors want to make sure they can run an as much Linux as possible. Before that happens, I think we'll continue to see extremely slow adoption by commercial vendors.
That being said, personally, I'm quite happy with most of the OSS out there. But keep in mind commercial needs differ. And sometimes you just have to have commercial software. With April coming around, TurboTax is a good example. (OSS is great, but I don't think anyone's going to be interested in writing an OSS tax software, and I'm not sure how much I'd trust 0.64bpre33 of YetAnotherTaxSuite =) ).
While I can certainly see the usefulness of people using this with voice commands, I'm not sure this is a generally usable feature. Hopefully the distros keep the extension as a separate download.
Does anyone remember Lotus HAL? They tried to do the exact same thing for spreadsheets. And while it had quite a bit of novelty (probably even useful given the insane menu tree of Lotus), I'm not sure it really did all that well. And many others have tried NLP (natural language processing) controlled apps in the 80's. But they were always more confusing to use than the (now) standard menu layouts.
Having said that, I recently was playing with a Mac, and I really like their approach. They have a little "find" sort of entry field that will just highlight or point you to the right help entries with whatever you type. Personally, I think that would be a better way to incorporate NLP.
5. Profit ?!
Oh wait, you're a scientist? Umm...
5. Continue working as TA to pay off student loans!
Actually, this makes perfect sense to me. Java's real problem is that the VM is tied to the language (Java people would disagree with me, but I challenge you to show me a Java Applet written in C).
I want a web-based VM/OS that really is just that, an OS (ala Inferno/Plan9). Let me as a programmer decide what language I want to write the thing in. Python, Java, C, C++, Intercal, whatever.
Java, C#/Mono, etc... all suffer from this problem. (Well that's not exactly true, .Net is probably the closest in offering a real VM OS... but they really don't talk about languages outside of C# and VB).
Now I'm not sure x86 is the "best" platform to use as your "platform independent architecture." Though it is definitely one of the most prevalent and well supported architectures out there.
The upshot of all this, though, is that we can get Linux running in a web browser (I'm sure someone will figure out some cleaver caching), which will *finally* get us all of our Gnome/KDE/Xaw tools available to larger audiences.
This means *finally* a write once, run anywhere world.
And it means we've just turned all web application developers into Linux developers.
Maybe *you* don't.... But I intend to run my company like my political campaign, "I promise to do the exact opposite of whatever my opponent says!"
sweet, so when're we going to have vodka cooled computers?
The problem I have with MSWord style version tracking is that it's a bit incongruent with my software version tracking. What I'd like to see is a way for OOo to have maybe some type of plugin support for third party version tracking, so that I can tie into subversion for example. Then all we need is a generic OOo diff'ing mechanism and we're done.
ie. I'd like to be able to do a diff between two documents and see things in a similar fashion to the unix diff command. This is something I can't easily do with MSWord documents either, although the way I see most people save multiple copies of their documents, it'd probably be invaluable. (Though I believe there are 3rd party apps for MSWord to do that).
Granted, I do understand that storing editing changes within the document itself is perhaps solving a different problem and has it's own uses.
Oh you're right it was rxvt not xterm that was indeed the fastest. Here's some simple performance numbers I got:
yes | dd of=/tmp/y.txt bs=1024 count=10240
10485760 bytes (10 MB) copied, 0.271632 seconds, 38.6 MB/s
(for calibration purposes)
dd if=/tmp/y.txt of=/dev/null
10485760 bytes (10 MB) copied, 0.0366388 seconds, 286 MB/s
gnome-terminal: dd if=/tmp/y.txt
10485760 bytes (10 MB) copied, 22.3385 seconds, 469 kB/s
xterm (jump): dd if=/tmp/y.txt
10485760 bytes (10 MB) copied, 57.5998 seconds, 182 kB/s
konsole: dd if=/tmp/y.txt
10485760 bytes (10 MB) copied, 32.9735 seconds, 318 kB/s
linux text console: dd if=/tmp/y.txt
3971584 bytes (4.0 MB) copied, 288.027 seconds, 13.8 kB/s
(I aborted it cause it took too long)
rxvt: dd if=/tmp/y.txt
10485760 bytes (10 MB) copied, 7.40936 seconds, 1.4 MB/s
This is on FC6 with a cheapy Quadro FX 550 and an intel core2 6300@1.86GHz.
My initial statement that xterm was faster appears to be wrong at least on this hardware.
But clearly rxvt is doing something right that no one else is doing.
Unfortunately, in some cases, UI responsiveness directly affects actual performance.
I was surprised to discover one day that running builds with lots of compiler output in a gnome-terminal (I believe KDE's terminal was the same) was significantly slower than running it in a text console. (Actually it was a Windows friend who was pointing out one of the deficiencies in Linux, but that's another story).
Anyway, turns out xterm is still probably one of the best X terminal programs out there, especially in terms of performance. I think one of the ways it's able to get this speed is with something it calls "jump scroll". Though if I recall correctly, even with jump scroll off xterm outperformed many of the other terminals.
What I think is happening in the other terminals is that they're actually causing the main application to block as their writing to the screen. If that's the case... well it's very dumb. Sorry I don't have actual performance numbers anymore... it's been a while since I've looked at it. In fact it was probably around the FC2 or FC3 days, so who knows maybe it's been fixed since then?
I don't get it. How's this software gonna tell if I was looking at porn by checking my breath?
When I was considering IM solutions for my company, I was looking into SILC, as that lets me run my own servers in addition to keeping traffic encrypted. I know that wasn't part of your original question. But it may be something you want to look into. Pidgin apparently has SILC client support built-in as well.
In fact hardware RAID is _only_ really useful for throughput. If you care about data integrity during a failure, RAID is really bad (even when mirroring). The reason is because RAID doesn't specify how the data is actually stored on the disk. If you're using a hardware RAID controller and your controller dies, you've lost all your data. You don't always even have the option of buying a new controller, as firmware can change even with the same model.
It's for this reason that I only trust software RAID (linux in particular, of course), whenever I do use RAID. I know I can always take the disk and load it up on another Linux machine without difficulty. The same can't be said for any hardware RAID format. (please correct me if I'm wrong).
It's not specifically JavaScript that's the problem. The problem is thinking that one language will solve all application requirements.
What we need is a way to write applications for this (web) platform with any language you want/need... just like the desktop.
Ideally we'd first have a VM of sorts on the browser... Separate the language from the execution. This would allow people to use their language of choice, and to take advantage of existing languages in order to write web-based display applications. For example, if you look at all the display methods right now: JavaScript, Flash, Java applets, etc. They all have pros and cons to their underlying technologies and browser tie-ins, but they're all tied to the specific language... I may like Java's concept of having a VM/byte-code interpreter, but I'm stuck with doing everything in Java. For some tasks, that just may not be ideal.
Once you've got that separation, then you can do some interesting things and actually learn past lessons. This whole concept of networked computing, remote displays, and server-oriented applications is actually quite old. The primary thing that's changed in the past 20 years is that we have smarter terminals.
So the next step is to develop something like X11 (or perhaps just extend X11?), but take advantage of the fact that we have smart terminals. Allow for the widgets and toolkit stuff (eg. gtk, Qt, etc.) to be loadable onto the remote display. This would provide the benefit that we want... low network overhead and high user interactivity for applications.
This would also allow us to standardize on UI toolkits much more so than we do now with AJAX, et. al. But because the UI can now be standardized, they can also be cached. Once you download a toolkit, you don't need to download it again.
But at the same time if some developers don't like the toolkit, you could easily have others without having to re-write your entire infrastructure. (Think Xaw, Motif, GTK, Qt. If you think that's too many, try to count the number of display toolkits commonly used in today's web application space).
The other benefit this gives you is the ability to just write applications once. You'd actually be able to share code bases when trying to support applications on the desktop and on the web. And this would be no more work than supporting, say Windows and Mac.
So the mistake we actually have has developers (in my view) is not recognizing that the web is a platform just like any other platform. And that we should treat it as such.
I'm not sure that's an either/or there. With a tripod that high, you'd may still have similar stabalization issues. Even assuming a perfectly rigid structure unaffected by the wind, you may have vibrations from the ground. Anyone still in school care to do the calculations?
I'm doing non-realtime embedded work it my current company and my previous one. And I can say that we definitely would like strong C and networking skills, with some hardware familiarity. Some ability to comprehend other discipilines like SQL, PHP, HTML, etc. are also starting to be important in this field as everything's starting to incorporate web pages and web-based configuration.
But even discounting the higher level languages, we've had a horrible time finding anyone with anywhere near the skills we'd need. And we're in Irvine, CA... theoretically one of the tech centers in SoCal.
I'd actually think this field would be growing _because_ the harddware costs are getting lower, and it's becoming easier to just put Linux on everything.
They might be thinking that a jamming signal is typically directional based on where you know the receiver is. I don't know if that's true or not, but that would make sense if you're thinking a stealth antenna avoids jamming.
Apple's insight there was really just how useless those features are. I'm not saying people won't take advantage of them if they're there, but I'm not convinced it really ads much to the "phone experience." And generally I think it's just too costly to use anyway.
Most phone makers/carriers have lost sight of the primary purpose of the phone: to communicate with people, ideally as easy as possible. While cameras and mp3 playing is neat, and could add some coolness to an otherwise boring phone, you can't skimp on good sound quality, noise reduction, etc. I can't personally say that the iPhone is good on any of those fronts either. I've yet to see a cell phone that's a good basic communication device first.
As an example, go out to your local cell provider and see just how many phones have cameras with buttons on the side that you can't lock! Or try to find a phone that actually mentions its audio input/output response.
But if Apple is able to address even a handful of these sorts of problems, it's no wonder they'd be popular... they'd have no competition! I mean sheesh one of the primary things that would make me switch over is simply the ability to save my voicemail onto my computer!
Ok, I'm done complaining now.
Can we get rid of the obvious Microsoft plant heading up GNOME? ;-)
The only way to win is not to play.
My initial reaction to the iPhone was the same. I like having buttons and being able to use my devices without looking at them. But then I realized that the cell phone industry has been making things worse and worse over the years. I simply can't operate my own phone without looking at it because of all the "ergo" and fancy styling they do with the buttons. On top of that, no one really remembers phone numbers anymore. I have to look at the phone to dial anyway (though I suppose I /could/ learn how to add a speed dial number).
On top of that, many phones have side buttons that simply cannot be locked/disabled. I know many people who keep their phones in their pockets/purses who just get the phones in weird modes or take thousands of snapshots and lose battery life because of this.
I will admit, though, that I do find the side volume control buttons very convenient. (Incidentally, I spent a good deal of time finding a phone that did still have a lockout mode that worked for the side
buttons.)
Well, I guess their work has advanced, so maybe not a repost exactly. But there was a slashdot covering the same group back in November:
/ 15/134225
http://hardware.slashdot.org/article.pl?sid=06/11
http://news.bbc.co.uk/2/hi/technology/6129460.stm
Unfortunately, I don't think it'll help you in the Windows world. But for *nix, I've found dmalloc to be quite simple to use but very effective.
http://dmalloc.com/releases/
Anyone remember Inferno and the IE Plugin they made for it? http://www.vitanuova.com/inferno/plugin/index.html
This is a full OS as a web plugin. Quite small and fast. If you want to "web-icize" linux, I'd suggest making a port of the linux kernel to a mozilla plugin, then write a console/X11 driver, and you're set. Now we can take advantage of all Linux tools in a browser, and we might finally have something better than all this Java / AJAX nonsense.