I am proud of some code I have written, ashamed of other code I have written.
I hold all code to the standard of elegance. I think elegance is largely a matter of taste, but there are absolutes. Repetetive code is not elegant. Large blocks of code are not elegant. Special cases are not elegant.
Recently, I have been getting the impression that whether the code I write is elegant mostly depends on the circumstances. Given enough freedom, I will write elegant code. When constrained by the language, time, or the code I have to interface with, my code often comes out less elegant than I could wish.
The ugliest code comes when (1) the language does not provide powerful enough abstractions (which I could use to contain the mess), (2) the library I have to work with is buggy, and (3) I am pressed for time. I guess the process is somewhat like this:
1. Use trial and error, and copy-pasting from the 'net, to write lots of snippets of code, until you hit one that works. 2. Copy-paste that one and adapt it to all places you need something like it. 3. Be happy that it seems to work now, and hope you never have to deal with it again.
Whereas my normal coding flow is something like:
1. Review the requirements and available building blocks. 2. Design a solution that implements using the available building blocks. 3. Look for patterns you can abstract from and code that can be re-used. 4. Implement the solution with a minimal amount of self-documenting code, with comments in the parts you can't make self-documenting. 5. Document what you've implemented, why, and how others can use it.
I'll hold my cheers until the government actually starts _using_ open formats.
There is also an approved motion, filed in 2002, that "requests the government to ensure that, by 2006, all software used in the public sector complies with open standards" (full (dutch) text of the motion).
This is what we want. This is what we _should_ have. It's outrageous for a government to force us to deal with prorprietary formats.
Furthermore, the motion expresses concern about the cost of the government using proprietary software that uses proprietary formats, and requests that the government "stimulate the adoption and development of open-source software in the public sector".
Regardless, the (previous) government inked a $$$ deal with Microsoft, apparently without even considering alternatives. I do some work for government agencies, and Windows is everywhere. Having said that, Linux is, too. I don't know about document formats they use for interacting with citizens; they always give me paper forms. But in my communications with them, it's Outlook and MS Word and Excel.
It's now 2007, one year past the target of the motion, and there's a long way to go still.
``VIM has rightfully taken the place of standard vi implementations as the spiritual successor to vi''
Err, no, not for me. For me, the beauty of vi is that it is light. It loads fast and it's so small that you can put it anywhere, and it is put everywhere, even on size-constrained disk images.
VIM, however, isn't small and doesn't load fast. It's not in the same niche as vi. It's in the niche where you can get pretty much any editor you want. And, frankly, I think vi and its offspring have a horrible user interface. So when I can have any editor I want, it won't be any vi derivate.
I think the problem with nuclear energy is that whether it is actually problematic is largely irrelevant. They told us it was a good idea before. Then we got cancer, worldwide panic, and a disposal problem. No matter how many times you tell us it's _really_ safe now and all the problems have been solved, we're not going there again.
``Vorbis is pretty much dead. While its quality is good, Vorbis has quite high performance requirements just for decoding (negligible on current desktop PCs, but not on portables that run on battery).''
Yes and no. Yes, decoding Vorbis was more CPU-intensive than MP3 last time I checked. No, this isn't actually a problem. There are quite a number of portable devices that decode Vorbis without any problems. Dead? I don't think so.
The real questions are why most companies seem to be actively ignoring Vorbis, and why consumers aren't rallying behind it more.
I find it incredible that a hard disk vendor would make disks that are incompatible with Linux in this day and age. Disks are one thing that pretty much always works under Linux, so this makes these Seagate drives really stand out (it would be a different story if it was, say, graphic cards). And it makes them stand out in a bad way. Linux may still have a small share of the consumer desktop market, but anyone who, at this point, thinks that Linux isn't serious is seriously deluded.
Being on the list of companies that released products that are incompatible with Linux is not a Good Thing. Doing so in a market where there are standards (IDE, USB mass storage,...) is really bad. For all intents and purposes, these products are simply _broken_. It's as if they deliberately made them not work with Linux. Why anyone would want to do that is beyond me.
``I do have to note that, having had experience with both Perl and Python, Ruby isn't bad at all. It's different in some ways, yeah, but so is Java, or C++, or C#. It's more a matter of taste, for a developer.''
I am not sure how you intended this to be taken, but if you meant to imply that the differences between all the languages you mentioned are just a matter of taste, I must disagree.
The languages you mentioned differ on features that have a very real impact on productivity, reliability and maintenance. I would say that goes beyond being a matter of taste.
One example I would like to mention is metaprogramming. Metaprogramming is, basically, letting a program write your program for you. It is very useful, because it can eliminate repetition in your code, which allows you to be more productive and introduce fewer bugs (the alternative to metaprogramming is usually "copy, paste, adapt", which is a rich source of errors).
As a Lisper, I am very sensitive to this issue; my hands itch each time I recognize a repeating pattern in code, and I resent sometimes having to leave the repetition there.
Now, of the languages you mentioned, Ruby is pretty strong on metaprogramming and Java isn't. I think Java actually offers some metaprogramming, but all Java code I've seen and written is full of things like "this.x = x; this.y = y;..." and "x.setFoo(y.getFoo()); x.setBar(y.getBar());...", "public static void oogle(...) throws A, B, C {... } public static void boogle(...) throws A, B, C {... }..." and other stuff that makes my skin crawl.
On the other hand, Java has static typing, which catches many errors at compile time, whereas Ruby has dynamic typing, which lets type errors slip until the wrong code actuall gets executed, which Murphy's law dictates will cause your program to blow up when an important customer is doing something critical.
On the gripping hand, having come back to Java development after years of blissful absence, I see that more and more Java code is being replaced with XML, throwing overboard the type checking and run-time performance advantages of Java...
Having worked on web sites using Rails in a previous job, I have to say I love many things about the framework. Like Ruby, it gets a lot of things right, and a few things very wrong. On the whole, I found it great to work with.
Recently, a friend told me that scalability was a major concern with Rails. I am not aware of any issues with that with the sites I worked on (which are pretty high traffic), but I left the project before the sites went live, so I can't say for sure that there weren't any issues. Can anyone here chime in on whether that has ever been a problem with scalability in Rails, what the causes of the problems are, and whether Rails 2 does anything to fix them?
Soon, the *AA will be forced to deal with a strange new concept...competition.
Soon, they will find that they are not the only ones prosecuting copyright violators...
Soon, they will be struggling to keep ahead of the organizations that prosecute GPL violations!... and yes, these organizations _will_ take on the *AA, and there _will_ be a film at 11!
I see at least one essential difference between DRM at non-competes. Where both non-competes have a limited lifetime and thus eventually will stop holding you back, DRM makes your content inaccessible for _ever_.
``...every application in the world sucks, save only one. Hardly a defensible position.''
On the contrary. I think you will find many people who agree with this view. The sad truth is that a lot of sofware does suck, and the rare jewels that are of great quality are very much the exception.
How about, instead of deliberately locking out IE users (and accidentally locking out some non-IE users due to faulty browser detection), we just made our web pages standards compliant, with all the glory we can muster, and let browsers with faulty implementations lock themselves out?
Bring out the translucent PNGs, the padding, the XML and XHTML declarations and the DOM access. And don't forget to let your pages degrade gracefully; use images and JavaScript only to enhance. We don't want to lock out text browsers, spiders, or users with disabilities. We don't actually want to lock out anyone. We just don't want to be bogged down by IE anymore. We want to make great web sites. If your browser fails to render them, because it fails to comply to standards...well, you can always use a browser that does implement the standards. They're freely available for every platform.
If we're going to make modifications on both ends, we can come up with something much better than what I described. But the scheme I described is completely client-side; the server just handles it like it does any other password. Therefore, only your web browser needs to be modified, rather than every web site on the planet.
I can't answer which sites will actually store your passwords and which ones will only store a one-way hash of it, but I can tell you that some customers I've developed sites for insisted that the passwords be stored in cleartext. So "many sites store your password in cleartext" is my best guess.
Also, even if the site doesn't store your password in cleartext, it will still be sent to them as cleartext. Even if it goes over SSL, the site itself will be able to decrypt it. So, one way or another, They have your password.
I would like to suggest a feature that could be added to browsers. An idea to think about; not a request for implementation just yet. But here's the idea. Let the browser perform the one-way hashing. You enter your password, the browser hashes it, and the hashed value is sent to the site. You can use a different hash for every site, and thus use the same password on your side, but send different values to different sites. That way, no site can pick up your password and use it with another site. You are still open to replay attacks on the same site if the site doesn't protect against that (e.g. by using SSL), but it's a lot better than things are now. You never send out your actual password, so nobody ever gets to know it.
I don't have time to RTFA before I go to work, but perhaps someone could answer these questions for everyone's benefit:
1. Is this the kind of standard that everybody can implement, or the kind of standard that will be used by PDF proponents to wave under the boss's nose and say "it's a Standard!" to get their format used over other (perhaps more open) formats?
2. Does the standard extend to all the extra that are in Acrobat Reader but not in most other PDF readers (forms, annotations, etc.)? In my experience, PDF works fine as a print representation of a document, but some people love to use it for forms that have to be filled out, or for attaching comments to a document you sent them, and this currently causes interoperability problems.
``You've simply fooled yourself into thinking the process is simpler than it is while screwing your customers out of their development dollars.''
Which, of course, makes good business sense. At least until customers start selecting on maintenance/improvement cost instead of initial development quote.
It wouldn't be so hard to take these organizations seriously if they didn't use every dirty trick in the book, including breaking the laws they claim to enforce.
I can almost imagine them having fallen into the trap of "open source = public domain, therefore we can do whatever we want"; except that MPAA deals with copyright infringement all the time, so they _should_ know better.
On a side note, this is a good illustration of the difference between open source and Free software: Free software is what requires the MPAA to make the source code available, whereas open source doesn't necessarily impose that requirement.
I thought "power user" was somewhat generally understood as a very demanding kind of user. The kind who has made a significant effort to set up everything just so (things like small icons to fit many of them on the screen, lots of eye candy, etc.), but who are still Users and thus stop short of taking matters into their own hands, instead complaining to system administrators and developers when something isn't right.
Relevant to this discussion is that power users will have memorized many of the obscure settings, menus, and perhaps keyboard shortcuts and applications that normal users don't know about. Thus, if KDE changes these, power users will be more affected than pretty much anyone else - normal users will probably only really notice a few changes, and, generally, people won't care much, because the desktop environment is just a tool they use to get work done. But power users, having spent a lot of time to get the desktop just the way they want it, and being proud of the work, will see a lot of their work undone or messed up...and that hurts.
Yup. What I think causes the pain is just cramped muscles. For me at least, these happen because of stress. I get RSI symptoms even when not doing any of the typical risky activities. What helps is just doing something with your hands while not under stress. Like some kind of sport you enjoy. Rock climbing, in your case. Posting on Slashdot, in mine.;-)
I get RSI symptoms from driving more than from typing, so I'll second that. But the factor I've found contributes most to RSI is _stress_. I can drive without problems for hours, and I can type at a keyboard all day in the wrongest postures, no problem at all. But the first few days on a new job I need to really take it slow, and if I put myself behind the wheel when worked up about something, my hands and whole upper body will hurt in a matter of minutes.
I really think stress is the real culprit. Unfortunately, it's very hard to stop...
If I had mod points, I'd mod you up. As it is, I'll just say you are spot on. Oh, and for the record, people do pick on the EU. I know, I live there. And we're (that is, some people are) trying to cut the subsidies and import barriers and all those, but, as you can imagine, the people benefiting from them scream bloody murder every time. It's a huge mess. Such is politics.
``There's only one problem, Google's main competitors Windows Live Hotmail and Yahoo Mail far surpassed Gmail this year with their own capacity.''
Problem? On the contrary! This is great. It's competition at work, improving things for users. Google offered lots of storage. Now it's competitors offer more. In response, Google will offer more. Whichever of these services you are using, you will get a better deal. The only problem here is how you can put all that space to good use.
I was researching this the other day. I was trying to find a replacement for my VIA EPIA SP8000E (it's a piece of junk; almost everything causes it to freeze or not boot).
Requirements: Low power consumption. Low noise. Enough juice to run a decent web browser. Linux-compatible. Cheap.
Being fed up with VIA, I first looked to laptops. Power consumption about 20 Watts, good. Need to be a bit more careful about the noise, but you can find quiet laptops no problem. Any laptop probably smokes the SP8000E performance-wise, so that's good too. However, I couldn't find a decent laptop for under around 500 euros, even second hand.
Eventually, I bought a Jetway J7F2-EDEN fanless motherboard/cpu combo, a nice case with a passive power supply, and a gig of RAM for about 300 euros. Disks, display, and keyboard will be taken from my old system, as they would have been in the case of a laptop. Power consumption should be about 20 Watts. The system has no moving parts other than the disks. Performance ought to be better than what I have. And it's cheap.
So, I guess, there's something for everyone. If you want to carry the system, or are OK using a laptop screen, keyboard, and mouse-substitute, get a laptop. Will be about 500 euros. If you don't want to carry it and want full-size input devices and screen, get a system like the one I got. Will also cost you about 500 euros if you have to buy the disk, keyboard, mouse, and monitor. If you want _really_ low power consumption and a PC, get the one mentioned in the story. Again, it will be around 500 euros, including monitor, disk and input devices. Word of warning: I work with machines like that at work and they are really really slow for today's standards.
``It offers a neutral Internet connection with no bandwidth caps or throttling, and it makes a point of creating wireless access points at the end of each DSL connection that can be used, for free, by the public.''
Sounds great for the consumers, but how does the company generate revenue? They will still have to pay the bills.
Slashdot Mirror
I am proud of some code I have written, ashamed of other code I have written.
I hold all code to the standard of elegance. I think elegance is largely a matter of taste, but there are absolutes. Repetetive code is not elegant. Large blocks of code are not elegant. Special cases are not elegant.
Recently, I have been getting the impression that whether the code I write is elegant mostly depends on the circumstances. Given enough freedom, I will write elegant code. When constrained by the language, time, or the code I have to interface with, my code often comes out less elegant than I could wish.
The ugliest code comes when (1) the language does not provide powerful enough abstractions (which I could use to contain the mess), (2) the library I have to work with is buggy, and (3) I am pressed for time. I guess the process is somewhat like this:
1. Use trial and error, and copy-pasting from the 'net, to write lots of snippets of code, until you hit one that works.
2. Copy-paste that one and adapt it to all places you need something like it.
3. Be happy that it seems to work now, and hope you never have to deal with it again.
Whereas my normal coding flow is something like:
1. Review the requirements and available building blocks.
2. Design a solution that implements using the available building blocks.
3. Look for patterns you can abstract from and code that can be re-used.
4. Implement the solution with a minimal amount of self-documenting code, with comments in the parts you can't make self-documenting.
5. Document what you've implemented, why, and how others can use it.
I'll hold my cheers until the government actually starts _using_ open formats.
There is also an approved motion, filed in 2002, that "requests the government to ensure that, by 2006, all software used in the public sector complies with open standards" (full (dutch) text of the motion).
This is what we want. This is what we _should_ have. It's outrageous for a government to force us to deal with prorprietary formats.
Furthermore, the motion expresses concern about the cost of the government using proprietary software that uses proprietary formats, and requests that the government "stimulate the adoption and development of open-source software in the public sector".
Regardless, the (previous) government inked a $$$ deal with Microsoft, apparently without even considering alternatives. I do some work for government agencies, and Windows is everywhere. Having said that, Linux is, too. I don't know about document formats they use for interacting with citizens; they always give me paper forms. But in my communications with them, it's Outlook and MS Word and Excel.
It's now 2007, one year past the target of the motion, and there's a long way to go still.
``VIM has rightfully taken the place of standard vi implementations as the spiritual successor to vi''
Err, no, not for me. For me, the beauty of vi is that it is light. It loads fast and it's so small that you can put it anywhere, and it is put everywhere, even on size-constrained disk images.
VIM, however, isn't small and doesn't load fast. It's not in the same niche as vi. It's in the niche where you can get pretty much any editor you want. And, frankly, I think vi and its offspring have a horrible user interface. So when I can have any editor I want, it won't be any vi derivate.
I think the problem with nuclear energy is that whether it is actually problematic is largely irrelevant. They told us it was a good idea before. Then we got cancer, worldwide panic, and a disposal problem. No matter how many times you tell us it's _really_ safe now and all the problems have been solved, we're not going there again.
``Vorbis is pretty much dead. While its quality is good, Vorbis has quite high performance requirements just for decoding (negligible on current desktop PCs, but not on portables that run on battery).''
Yes and no. Yes, decoding Vorbis was more CPU-intensive than MP3 last time I checked. No, this isn't actually a problem. There are quite a number of portable devices that decode Vorbis without any problems. Dead? I don't think so.
The real questions are why most companies seem to be actively ignoring Vorbis, and why consumers aren't rallying behind it more.
I find it incredible that a hard disk vendor would make disks that are incompatible with Linux in this day and age. Disks are one thing that pretty much always works under Linux, so this makes these Seagate drives really stand out (it would be a different story if it was, say, graphic cards). And it makes them stand out in a bad way. Linux may still have a small share of the consumer desktop market, but anyone who, at this point, thinks that Linux isn't serious is seriously deluded.
...) is really bad. For all intents and purposes, these products are simply _broken_. It's as if they deliberately made them not work with Linux. Why anyone would want to do that is beyond me.
Being on the list of companies that released products that are incompatible with Linux is not a Good Thing. Doing so in a market where there are standards (IDE, USB mass storage,
``I do have to note that, having had experience with both Perl and Python, Ruby isn't bad at all. It's different in some ways, yeah, but so is Java, or C++, or C#. It's more a matter of taste, for a developer.''
..." and "x.setFoo(y.getFoo()); x.setBar(y.getBar()); ...", "public static void oogle(...) throws A, B, C { ... } public static void boogle(...) throws A, B, C { ... } ..." and other stuff that makes my skin crawl.
I am not sure how you intended this to be taken, but if you meant to imply that the differences between all the languages you mentioned are just a matter of taste, I must disagree.
The languages you mentioned differ on features that have a very real impact on productivity, reliability and maintenance. I would say that goes beyond being a matter of taste.
One example I would like to mention is metaprogramming. Metaprogramming is, basically, letting a program write your program for you. It is very useful, because it can eliminate repetition in your code, which allows you to be more productive and introduce fewer bugs (the alternative to metaprogramming is usually "copy, paste, adapt", which is a rich source of errors).
As a Lisper, I am very sensitive to this issue; my hands itch each time I recognize a repeating pattern in code, and I resent sometimes having to leave the repetition there.
Now, of the languages you mentioned, Ruby is pretty strong on metaprogramming and Java isn't. I think Java actually offers some metaprogramming, but all Java code I've seen and written is full of things like "this.x = x; this.y = y;
On the other hand, Java has static typing, which catches many errors at compile time, whereas Ruby has dynamic typing, which lets type errors slip until the wrong code actuall gets executed, which Murphy's law dictates will cause your program to blow up when an important customer is doing something critical.
On the gripping hand, having come back to Java development after years of blissful absence, I see that more and more Java code is being replaced with XML, throwing overboard the type checking and run-time performance advantages of Java...
Having worked on web sites using Rails in a previous job, I have to say I love many things about the framework. Like Ruby, it gets a lot of things right, and a few things very wrong. On the whole, I found it great to work with.
Recently, a friend told me that scalability was a major concern with Rails. I am not aware of any issues with that with the sites I worked on (which are pretty high traffic), but I left the project before the sites went live, so I can't say for sure that there weren't any issues. Can anyone here chime in on whether that has ever been a problem with scalability in Rails, what the causes of the problems are, and whether Rails 2 does anything to fix them?
Soon, the *AA will be forced to deal with a strange new concept...competition.
... and yes, these organizations _will_ take on the *AA, and there _will_ be a film at 11!
Soon, they will find that they are not the only ones prosecuting copyright violators...
Soon, they will be struggling to keep ahead of the organizations that prosecute GPL violations!
I see at least one essential difference between DRM at non-competes. Where both non-competes have a limited lifetime and thus eventually will stop holding you back, DRM makes your content inaccessible for _ever_.
``...every application in the world sucks, save only one. Hardly a defensible position.''
On the contrary. I think you will find many people who agree with this view. The sad truth is that a lot of sofware does suck, and the rare jewels that are of great quality are very much the exception.
How about, instead of deliberately locking out IE users (and accidentally locking out some non-IE users due to faulty browser detection), we just made our web pages standards compliant, with all the glory we can muster, and let browsers with faulty implementations lock themselves out?
Bring out the translucent PNGs, the padding, the XML and XHTML declarations and the DOM access. And don't forget to let your pages degrade gracefully; use images and JavaScript only to enhance. We don't want to lock out text browsers, spiders, or users with disabilities. We don't actually want to lock out anyone. We just don't want to be bogged down by IE anymore. We want to make great web sites. If your browser fails to render them, because it fails to comply to standards...well, you can always use a browser that does implement the standards. They're freely available for every platform.
If we're going to make modifications on both ends, we can come up with something much better than what I described. But the scheme I described is completely client-side; the server just handles it like it does any other password. Therefore, only your web browser needs to be modified, rather than every web site on the planet.
I can't answer which sites will actually store your passwords and which ones will only store a one-way hash of it, but I can tell you that some customers I've developed sites for insisted that the passwords be stored in cleartext. So "many sites store your password in cleartext" is my best guess.
Also, even if the site doesn't store your password in cleartext, it will still be sent to them as cleartext. Even if it goes over SSL, the site itself will be able to decrypt it. So, one way or another, They have your password.
I would like to suggest a feature that could be added to browsers. An idea to think about; not a request for implementation just yet. But here's the idea. Let the browser perform the one-way hashing. You enter your password, the browser hashes it, and the hashed value is sent to the site. You can use a different hash for every site, and thus use the same password on your side, but send different values to different sites. That way, no site can pick up your password and use it with another site. You are still open to replay attacks on the same site if the site doesn't protect against that (e.g. by using SSL), but it's a lot better than things are now. You never send out your actual password, so nobody ever gets to know it.
I don't have time to RTFA before I go to work, but perhaps someone could answer these questions for everyone's benefit:
1. Is this the kind of standard that everybody can implement, or the kind of standard that will be used by PDF proponents to wave under the boss's nose and say "it's a Standard!" to get their format used over other (perhaps more open) formats?
2. Does the standard extend to all the extra that are in Acrobat Reader but not in most other PDF readers (forms, annotations, etc.)? In my experience, PDF works fine as a print representation of a document, but some people love to use it for forms that have to be filled out, or for attaching comments to a document you sent them, and this currently causes interoperability problems.
3. Why did France vote against?
``You've simply fooled yourself into thinking the process is simpler than it is while screwing your customers out of their development dollars.''
Which, of course, makes good business sense. At least until customers start selecting on maintenance/improvement cost instead of initial development quote.
It wouldn't be so hard to take these organizations seriously if they didn't use every dirty trick in the book, including breaking the laws they claim to enforce.
I can almost imagine them having fallen into the trap of "open source = public domain, therefore we can do whatever we want"; except that MPAA deals with copyright infringement all the time, so they _should_ know better.
On a side note, this is a good illustration of the difference between open source and Free software: Free software is what requires the MPAA to make the source code available, whereas open source doesn't necessarily impose that requirement.
I thought "power user" was somewhat generally understood as a very demanding kind of user. The kind who has made a significant effort to set up everything just so (things like small icons to fit many of them on the screen, lots of eye candy, etc.), but who are still Users and thus stop short of taking matters into their own hands, instead complaining to system administrators and developers when something isn't right.
Relevant to this discussion is that power users will have memorized many of the obscure settings, menus, and perhaps keyboard shortcuts and applications that normal users don't know about. Thus, if KDE changes these, power users will be more affected than pretty much anyone else - normal users will probably only really notice a few changes, and, generally, people won't care much, because the desktop environment is just a tool they use to get work done. But power users, having spent a lot of time to get the desktop just the way they want it, and being proud of the work, will see a lot of their work undone or messed up...and that hurts.
Yup. What I think causes the pain is just cramped muscles. For me at least, these happen because of stress. I get RSI symptoms even when not doing any of the typical risky activities. What helps is just doing something with your hands while not under stress. Like some kind of sport you enjoy. Rock climbing, in your case. Posting on Slashdot, in mine. ;-)
I get RSI symptoms from driving more than from typing, so I'll second that. But the factor I've found contributes most to RSI is _stress_. I can drive without problems for hours, and I can type at a keyboard all day in the wrongest postures, no problem at all. But the first few days on a new job I need to really take it slow, and if I put myself behind the wheel when worked up about something, my hands and whole upper body will hurt in a matter of minutes.
I really think stress is the real culprit. Unfortunately, it's very hard to stop...
If I had mod points, I'd mod you up. As it is, I'll just say you are spot on. Oh, and for the record, people do pick on the EU. I know, I live there. And we're (that is, some people are) trying to cut the subsidies and import barriers and all those, but, as you can imagine, the people benefiting from them scream bloody murder every time. It's a huge mess. Such is politics.
``There's only one problem, Google's main competitors Windows Live Hotmail and Yahoo Mail far surpassed Gmail this year with their own capacity.''
Problem? On the contrary! This is great. It's competition at work, improving things for users. Google offered lots of storage. Now it's competitors offer more. In response, Google will offer more. Whichever of these services you are using, you will get a better deal. The only problem here is how you can put all that space to good use.
Wow, that's a seriously awesome device! And it has enough RAM to actually do something useful with it. Thanks for the pointer!
I was researching this the other day. I was trying to find a replacement for my VIA EPIA SP8000E (it's a piece of junk; almost everything causes it to freeze or not boot).
Requirements: Low power consumption. Low noise. Enough juice to run a decent web browser. Linux-compatible. Cheap.
Being fed up with VIA, I first looked to laptops. Power consumption about 20 Watts, good. Need to be a bit more careful about the noise, but you can find quiet laptops no problem. Any laptop probably smokes the SP8000E performance-wise, so that's good too. However, I couldn't find a decent laptop for under around 500 euros, even second hand.
Eventually, I bought a Jetway J7F2-EDEN fanless motherboard/cpu combo, a nice case with a passive power supply, and a gig of RAM for about 300 euros. Disks, display, and keyboard will be taken from my old system, as they would have been in the case of a laptop. Power consumption should be about 20 Watts. The system has no moving parts other than the disks. Performance ought to be better than what I have. And it's cheap.
So, I guess, there's something for everyone. If you want to carry the system, or are OK using a laptop screen, keyboard, and mouse-substitute, get a laptop. Will be about 500 euros. If you don't want to carry it and want full-size input devices and screen, get a system like the one I got. Will also cost you about 500 euros if you have to buy the disk, keyboard, mouse, and monitor. If you want _really_ low power consumption and a PC, get the one mentioned in the story. Again, it will be around 500 euros, including monitor, disk and input devices. Word of warning: I work with machines like that at work and they are really really slow for today's standards.
``It offers a neutral Internet connection with no bandwidth caps or throttling, and it makes a point of creating wireless access points at the end of each DSL connection that can be used, for free, by the public.''
Sounds great for the consumers, but how does the company generate revenue? They will still have to pay the bills.