We are far past that point already. The industrial revolution has made it possible to produce far more stuff than we really need. Marketing as an industry sprung up in order to manufacture demand to support the supply. Billions of dollars are spent every year convincing people to spend more money than they need to.
The real problem is resources. You mentioned space, but I'd worry more about energy. The ridiculous levels of consumption that keep our economy growing at a steady rate are going to run up against that problem very suddenly.
If they can get AOL in on this too, it could be very bad.
Everyone being able to talk to everyone else would be nice, but there are big downsides if it's a closed network. If it ends up that 9X% of users are on a single A/M/Y-IM network then it would be very hard for anyone else to break into the market.
Google is in very direct competition with Yahoo, and Microsoft sees Google as the biggest threat to their dominance. Now, a couple of months after GTalk's release, Yahoo and MS are ganging together. They aren't doing this because they want their users to benefit (if they really cared they would've done this a long time ago). This is MS and Yahoo trying to keep Google from gaining a foothold in IM.
I really hope Jabber will take off, but this move makes it less likely. With everyone split up over AIM, MSN and Yahoo, Jabber could at least offer a means of unification. Now it's looking like we could get stuck with a single closed network.
If a handful of players lock up the network, innovation will die.
As far as I know Postgres-R is dead..? Slony-II is under development, and will provide synchronous / multi-master replication for PostgreSQL. (Slony-I is already available, but is asynchronous / single-master.)
Gotta love that company - maybe next they'll just send out beefy guys with baseball bats to break the kneecaps of anyone who sells refilled cartridges...
"By being beaten with this bat, you are agreeing to the following terms and conditions..."
There are cross-platform GUI toolkits. GTK, Qt, Tk, Swing, etc. Some, like wxWindows and SWT, provide a cross-platform interface to the native toolkits.
Are there open classes for developing GUIs, that are as easy to use as.NET (think that is what MFC has turned into?) that will work on Windows and Linux?
In theory you can use Mono and run.NET apps cross-platform. I haven't tried it though, so I don't know how well it works (I would expect MS to try to sabotage any cross-platform potential).
Maybe Linux should provide some kind of interpreter where I can take all the files used in this MFC app and make something at least similar in Linux, or maybe that is not possible, I don't know.
Well, there's Wine. It works (kind of) but is large and complicated, because MFC/Win32 are large and complicated.
It's far easier to go in the other direction. Use an API that abstracts out the platform-specific details. Suppose your app wants to open a window. So you have a function called "createWindow" or whatever, and all that code does is call the MFC window open function if it's on Windows, or the GTK function if it's on Linux, or whatever. So your app just says that it wants to open a window, and the abstraction layer works out the details of how to do it on that particular platform.
That's exactly the approach used by cross-platform GUI toolkits. Where they differ is in how much work they do themselves, versus how much they pass off to the underlying platform. Of the Java toolkits, for example, Swing uses native components as nothing more than a canvas. It renders buttons, scrollbars, and everything else itself, instead of using the native button and scrollbar components. That's why Swing apps usually look exactly the same across different platforms. SWT, on the other hand, does use the native components, and does little or no rendering itself. So SWT apps look like they belong on whatever platform they are running on, because they use the same components that native apps do.
Sure you'll run into the occasional platform-specific oddity. So work around it and move on. It's not a big deal. Certainly far less work than trying to code multiple single-platform versions, or re-writing an existing single-platform app to be portable.
And such problems are not limited to cross-platform development, either. You have to deal with differences even across multiple versions of the same platform.
You only have time to get a single version of the client ready so which OS do you support first?
All of them.
Cross-platform app development is only painful if you try to do it after the code has been targeted to a single platform. If you aim for portability right from the start, it isn't hard to do.
This particular device uses Linux, which brings up another question: should developers of open source software license their software so as to prevent it from being used in such killing devices?
Somehow, I doubt that people who would use the software for such purposes would be dissuaded by the licensing conditions.
Should work fine in IE. IE 5.5 and up can handle PNGs, as long as they don't contain any translucent pixels. All pixels must be completely solid or completely transparent, like GIFs (but with 24-bit color). Translucency can be made to work too, but requires a kludge.
One obvious benefit is that you don't need to lift a lot of fuel. But that's not really a big deal - the fuel accounts for a very small portion of the cost of a shuttle launch (a fraction of a percent I think*). A lot of it is maintenance. Launch and re-entry are very sensitive to small problems (see Challenger, Columbia). A space elevator would avoid most of those dangers. No more riding on top of an explosion, no more coming back down like a meteor. All an elevator needs is a firm grip on the cable, a motor strong enough to power the ride, and life support. That's a lot less to go wrong, which translates into lower cost.
* I've read somewhere that the shuttle holds less than a million dollars worth of fuel, while the cost of a single shuttle launch is hundreds of millions of dollars.
Jabber is a protocol. Gaim is a multi-protocol client. Gaim works well with Jabber networks (and YIM and AIM and MSN). Miranda IM does too, though it is Win32 only. Both are FOSS. Both are completely ad-free. People should use them, even if they never use Jabber.
It is generally better to use a multi-protocol client than Jabber gateways. The gateways tend to be feature-weak, for example most don't support file transfers or group chat.
By the way, if you do use the Jabber gateways (which is the only option if you are in love with some Jabber-only client), keep in mind that you aren't restricted to the ones available on the server you connect to. Many of the open Jabber servers allow their gateways to be used by any Jabber client anywhere on the network. The downside is that it is one more server that can go down when you're trying to message someone.
Jabber is a very good protocol. The ability to choose a server (and even set up your own) introduces a level of freedom that doesn't exist within Yahoo/AOL/MS-owned networks. The gateways are cool too.
we need to have the things, and if god forbid we ever have to use them, I'd like to see them work properly.
Indeed. It would suck if we were to only wipe out part of the human race. What would be the point of that? Worse still, with all the destruction from the ones that do go off, it could take thousands of years to set up another attempt at armageddon.
It's kinda like that time I was playing russian roulette. I noticed the "click" had a different sound to it than usual, but the damn thing didn't go off! I was playing russian roulette with a dud cartridge! I was so pissed off...
If you want to see how a good desktop environment renders text, look no further than Mac OS X.
Seen it. Not impressed. Many vertical strokes were anti-aliased to be two pixels wide when they should render one wide. It makes the text look blurry. I've seen that on Linux before too, though it's since been fixed (problem with the font hinting?).
I use Gnome. Looks great on my LCD with sub-pixel anti-aliasing. I suspect the problem with the screenshots is that they use the default fonts (the free Bitstream ones I think). I use the Microsoft fonts, mostly Verdana. Verdana may not be pretty but it's designed for on-screen readability, and renders well.
It must be great, because the authors are hardcore protocol geeks who know how to create a good network. You can tell because they used to run a web site. </sarcasm>
I think it is aimed at exactly the sort of people who claim to know what it is for. It's a computer, so of course there are a bunch of things it could be used for, and the small form-factor gives you the all of the usual non-desktop options that SFF systems are used in. All of these people who are saying "it's for $foo" are really just projecting their own ideas, and will likely go out and buy one and use it for $foo. Those who are saying "oh wait, it can't actually be used for $foo, because it lacks $bar" will probably go out and buy one anyway, and buy the add-on required for $bar.
The "it's for $foo" people must be working out great for Apple, as free advertising. All of the pundits out there (including Cringely) are collectively declaring more uses for the Mac Mini than Apple's marketing department could ever dream up, and spreading the word more widely than Apple's advertising budget could ever afford.
I was at work at the time. Exploring space from my desk at the office.:)
They only had this photo on the ESA Cassini-Huygens page at the time. I was happily stunned after messing with the URL and discovering a photo taken from Titan's surface.
Do we really need yet another bloated python p2p app?... it'll easily chew 40 MB's and gobble considerably more CPU time than a comparable program written in C/C++.
Do we really need another network-heavy (client and server) C/C++ app with multiple buffer overflows waiting to be exploited?
I, for one, am glad this thing is written in Python.
Slashdot Mirror
We are far past that point already. The industrial revolution has made it possible to produce far more stuff than we really need. Marketing as an industry sprung up in order to manufacture demand to support the supply. Billions of dollars are spent every year convincing people to spend more money than they need to.
The real problem is resources. You mentioned space, but I'd worry more about energy. The ridiculous levels of consumption that keep our economy growing at a steady rate are going to run up against that problem very suddenly.
If they can get AOL in on this too, it could be very bad.
Everyone being able to talk to everyone else would be nice, but there are big downsides if it's a closed network. If it ends up that 9X% of users are on a single A/M/Y-IM network then it would be very hard for anyone else to break into the market.
Google is in very direct competition with Yahoo, and Microsoft sees Google as the biggest threat to their dominance. Now, a couple of months after GTalk's release, Yahoo and MS are ganging together. They aren't doing this because they want their users to benefit (if they really cared they would've done this a long time ago). This is MS and Yahoo trying to keep Google from gaining a foothold in IM.
I really hope Jabber will take off, but this move makes it less likely. With everyone split up over AIM, MSN and Yahoo, Jabber could at least offer a means of unification. Now it's looking like we could get stuck with a single closed network.
If a handful of players lock up the network, innovation will die.
As far as I know Postgres-R is dead..? Slony-II is under development, and will provide synchronous / multi-master replication for PostgreSQL. (Slony-I is already available, but is asynchronous / single-master.)
"By being beaten with this bat, you are agreeing to the following terms and conditions..."
There are cross-platform GUI toolkits. GTK, Qt, Tk, Swing, etc. Some, like wxWindows and SWT, provide a cross-platform interface to the native toolkits.
In theory you can use Mono and run .NET apps cross-platform. I haven't tried it though, so I don't know how well it works (I would expect MS to try to sabotage any cross-platform potential).
Well, there's Wine. It works (kind of) but is large and complicated, because MFC/Win32 are large and complicated.
It's far easier to go in the other direction. Use an API that abstracts out the platform-specific details. Suppose your app wants to open a window. So you have a function called "createWindow" or whatever, and all that code does is call the MFC window open function if it's on Windows, or the GTK function if it's on Linux, or whatever. So your app just says that it wants to open a window, and the abstraction layer works out the details of how to do it on that particular platform.
That's exactly the approach used by cross-platform GUI toolkits. Where they differ is in how much work they do themselves, versus how much they pass off to the underlying platform. Of the Java toolkits, for example, Swing uses native components as nothing more than a canvas. It renders buttons, scrollbars, and everything else itself, instead of using the native button and scrollbar components. That's why Swing apps usually look exactly the same across different platforms. SWT, on the other hand, does use the native components, and does little or no rendering itself. So SWT apps look like they belong on whatever platform they are running on, because they use the same components that native apps do.
Yes, I have.
Sure you'll run into the occasional platform-specific oddity. So work around it and move on. It's not a big deal. Certainly far less work than trying to code multiple single-platform versions, or re-writing an existing single-platform app to be portable.
And such problems are not limited to cross-platform development, either. You have to deal with differences even across multiple versions of the same platform.
All of them.
Cross-platform app development is only painful if you try to do it after the code has been targeted to a single platform. If you aim for portability right from the start, it isn't hard to do.
Somehow, I doubt that people who would use the software for such purposes would be dissuaded by the licensing conditions.
Coolness aside, how is this better than blanketing the area with regular security cameras?
Should work fine in IE. IE 5.5 and up can handle PNGs, as long as they don't contain any translucent pixels. All pixels must be completely solid or completely transparent, like GIFs (but with 24-bit color). Translucency can be made to work too, but requires a kludge.
PNG support in IE sucks, but it does exist.
One obvious benefit is that you don't need to lift a lot of fuel. But that's not really a big deal - the fuel accounts for a very small portion of the cost of a shuttle launch (a fraction of a percent I think*). A lot of it is maintenance. Launch and re-entry are very sensitive to small problems (see Challenger, Columbia). A space elevator would avoid most of those dangers. No more riding on top of an explosion, no more coming back down like a meteor. All an elevator needs is a firm grip on the cable, a motor strong enough to power the ride, and life support. That's a lot less to go wrong, which translates into lower cost.
* I've read somewhere that the shuttle holds less than a million dollars worth of fuel, while the cost of a single shuttle launch is hundreds of millions of dollars.
In Soviet Slashdot, computers Turing-test YOU!
Famous last words.
No need. The US seems to be fucking itself just fine already.
Jabber is a protocol. Gaim is a multi-protocol client. Gaim works well with Jabber networks (and YIM and AIM and MSN). Miranda IM does too, though it is Win32 only. Both are FOSS. Both are completely ad-free. People should use them, even if they never use Jabber.
It is generally better to use a multi-protocol client than Jabber gateways. The gateways tend to be feature-weak, for example most don't support file transfers or group chat.
By the way, if you do use the Jabber gateways (which is the only option if you are in love with some Jabber-only client), keep in mind that you aren't restricted to the ones available on the server you connect to. Many of the open Jabber servers allow their gateways to be used by any Jabber client anywhere on the network. The downside is that it is one more server that can go down when you're trying to message someone.
Jabber is a very good protocol. The ability to choose a server (and even set up your own) introduces a level of freedom that doesn't exist within Yahoo/AOL/MS-owned networks. The gateways are cool too.
Indeed. It would suck if we were to only wipe out part of the human race. What would be the point of that? Worse still, with all the destruction from the ones that do go off, it could take thousands of years to set up another attempt at armageddon.
It's kinda like that time I was playing russian roulette. I noticed the "click" had a different sound to it than usual, but the damn thing didn't go off! I was playing russian roulette with a dud cartridge! I was so pissed off...
Many of my bookmarks are not appropriate for work or other places where the keyboard is not waterproofed.
Is there some way to keep some of my bookmarks across machines while still keeping some only on one machine?
That seems to be a problem with data syncing in general, actually. Not just bookmarks.
Trigger a mass extinction? Wouldn't that be redundant?
Seen it. Not impressed. Many vertical strokes were anti-aliased to be two pixels wide when they should render one wide. It makes the text look blurry. I've seen that on Linux before too, though it's since been fixed (problem with the font hinting?).
I use Gnome. Looks great on my LCD with sub-pixel anti-aliasing. I suspect the problem with the screenshots is that they use the default fonts (the free Bitstream ones I think). I use the Microsoft fonts, mostly Verdana. Verdana may not be pretty but it's designed for on-screen readability, and renders well.
Here's a photo of the cover.
It must be great, because the authors are hardcore protocol geeks who know how to create a good network. You can tell because they used to run a web site. </sarcasm>
I'm also amused by the "what is it for" crowd.
I think it is aimed at exactly the sort of people who claim to know what it is for. It's a computer, so of course there are a bunch of things it could be used for, and the small form-factor gives you the all of the usual non-desktop options that SFF systems are used in. All of these people who are saying "it's for $foo" are really just projecting their own ideas, and will likely go out and buy one and use it for $foo. Those who are saying "oh wait, it can't actually be used for $foo, because it lacks $bar" will probably go out and buy one anyway, and buy the add-on required for $bar.
The "it's for $foo" people must be working out great for Apple, as free advertising. All of the pundits out there (including Cringely) are collectively declaring more uses for the Mac Mini than Apple's marketing department could ever dream up, and spreading the word more widely than Apple's advertising budget could ever afford.
That's exactly what I was thinking yesterday when I first saw this photo from Titan's surface.
I was at work at the time. Exploring space from my desk at the office. :)
They only had this photo on the ESA Cassini-Huygens page at the time. I was happily stunned after messing with the URL and discovering a photo taken from Titan's surface.
Do we really need another network-heavy (client and server) C/C++ app with multiple buffer overflows waiting to be exploited?
I, for one, am glad this thing is written in Python.