Israel has the fucking US military behind them. They are also supposed to have nukes. At this point, I claim that Israel is a terrorist nation. I would gladly give the Lebanese nukes, if only to make it a level playing field.
Sysadmins write glue. They just deal with larger application libraries than programmers do (particularly if you consider apps and operating systems as libs).
How were they supposed to distribute without the Internet? Keep in mind that the Internet as a major distribution medium for media really took off after broadband came in.
Wouldn't that depend on who is hosting the spreadsheet? If it was a third party, I wouldn't trust it. As an inhouse hosted application with source available, I might (though I don't find web apps very useful in the first place).
Thin clients are better for such things. A centralised installation and a remote display. Thin clients can vary from VT100 to intelligent sunrays, so you don't need to worry about processing power either. Why waste money on those power hungry CPUs and hard disks all over the place, when you can centralise and manage those resources better.
If a P IV is sitting 90% idle, it can definitely serve 5 users.
The city's automobile-dependent nature holds implications for greenhouse gas emissions. Although Phoenix is the sixth-largest city in the United States, its public transit system accounts for just one per cent of the passenger miles that New York City's does. The reason is that Phoenix's booming population has spread so far across the desert; greater Phoenix, whose population is a little more than twice that of Manhattan, covers more than two hundred times as much land.[4]
That isn't scaling up. Phoenix has a mere 1 million people in the city, with 3.7 million in the metropolitan region. That's a pretty small city, except that it is slightly more spread out. Problems tend not to show up until the first couple of decades of growth have been passed, when all the buffering of infrastructure provided by the original planning is used up. Planning can handle regular growth, not exponential.
Contrast with cities which have scaled up, like New York, or Mumbai.
That paper you link to is basically showing how development should NOT occur.
Except that security is relative and a risk management function. Secure against what threats? At what cost? Earlier we had buffer overflows. Now the holes have just moved up the stack.
The cost of entry into the last mile is simple infrastructure cost, not regulatory. The problem is that the entity controlling the last mile now wants to regulate different types of traffic differently.
We are not speaking of control on total bandwidth either, we are speaking different classes of service within the same bandwidth class (not as in more money for more and/or guaranteed bandwidth, but as in "you can't use our competitors VoIP but you can use ours").
As long as the regulation requires hat all traffic of the same class be treated equally, there isn't a problem. The moment they start trying to offer differentiated services for different providers, there is a problem. They could always unbundle the local loop, and be banned from the content service business, whcih would be another way of enforcing net neutrality.
Your last mile is a monopoly, but usable by any service provider you choose, and you can choose the content providers you want because the service providers and last mile provider hold no stake in any of those.
As long as you don't travel, or use oil. Scaling high rises with mass transit based on electric power is far cheaper than getting resources to people who are spread out. Keep in mind that what you will lose out on is communication and travel.
Oh, and a few million immigrants from Asia looking for land could destroy your utopia quite easily. Just like the Europeans did to the native Americans.
10. India - should really focus on sea mines- no one's gonna hump it over the himalayas to attack. Too many Yeti.
1962 - China Pakistan - Kashmir (Google for Kargil, and Siachen), Rajasthan, Punjab.
I rather prefer big fucking nukes, and the willingness to use them. "Attack me, and I will reduce this planet to a slag heap" is a good deterrent to war. That does nothing to stop terrorists though.
I am not objecting to actual improvementz (which both KDE and GNOME have). What I am objecting to is the whole "one true windows interface" (minor nit), and the extremely tight coupling of the K* and G* components (major nit).
If I need one KDE app, or one GNOME app, I have to load a ton of libraries and waste precious memory (If I could afford it, I would have 16 GB of RAM here). That, to me, is painful. Just a Gtk app, not a big deal. QT app? No big deal.
But KDE and GNOME respond slowly, and spend time doing stuff which does not give me any benefit. As I keep getting reminded by developers from both sides, KDE and GNOME are meant to be complete environments and as such you should never need any application from the other at the same time.
So if I would rather use KDE's printing subsystem from a GNOME application, I have a ton of pain ahead. I tend to shy away from such tightly coupled environments.
My work involves running very tighly integrated systems, but the components are completely decoupled. We have migrated across components, replacing large parts of the system architecture without resource usage changes,
Tight coupling is usually bad (IE, Windows, Exchange, Lotus Notes). Loose coupling with well defined protocols is good.
The Unix command line offers a well defined protocol -- STDIN, STDOUT, STDERR, and text streams (everything is a file would have been nicer if fully implemented, but it is still close enough). However, applications are not tighly integrated. You can use BSD tools, GNU tools, different shells and the system still works in more or less the same way.
When GNOME and KDE achieve that level of coupling, I'll take a look at using them again.
So you assumed that since I was talking about integration, I must necessarily be proposing bloatware?
Tight coupling is generally the problem. Loose coupling is good. As long as your applications are extremely loosely coupled, integration isn't an issue.
Ideally, there would be a application core,and the GUIs would merely be frontends over it. So it wouldn't matter which language you used, what DE you used, all your applications would be consistent in using the same files for configuration.
Oh, and I use Linux (and BSD) because of the way they let me decide on my environment (which hasn't changed in look and feel for about 6 years). Neither KDE nor GNOME satisfy those goals.
Of course, any single scientist should not be trusted. However, when multiple scientists get the same results using the same methodology, then those results can be considered a bit more trustworthy.
Unix components are looselycoupled, and they let the user choose how to integrate them. I don't see the mention of loose coupling in the GP.
Oh, and the nature of the two main DEs essentially is that the integration part is left to the developers and not the users.
If the integration was done right, we would have a single file manager library, and two (or more) GUI wrappers on top of it. We don't have that kind of integration available in KDE/GNOME yet.
Slashdot Mirror
Israel has the fucking US military behind them. They are also supposed to have nukes. At this point, I claim that Israel is a terrorist nation. I would gladly give the Lebanese nukes, if only to make it a level playing field.
Sysadmins write glue. They just deal with larger application libraries than programmers do (particularly if you consider apps and operating systems as libs).
Cool, so you support the Indian developers and call center employees who are willing to work for far less?
Here. They did that already.
How were they supposed to distribute without the Internet? Keep in mind that the Internet as a major distribution medium for media really took off after broadband came in.
A slightly wrinkled mango is ripe. Deeper wrinkles indicate more/over-ripening.
Green mangoes are raw. Yellow/golden/red, but not wrinkled mangoes are underripe.
Ask me next April/May and I'll put up pictures.
One per nation, no vetos.
Wouldn't that depend on who is hosting the spreadsheet? If it was a third party, I wouldn't trust it. As an inhouse hosted application with source available, I might (though I don't find web apps very useful in the first place).
Thin clients are better for such things. A centralised installation and a remote display. Thin clients can vary from VT100 to intelligent sunrays, so you don't need to worry about processing power either. Why waste money on those power hungry CPUs and hard disks all over the place, when you can centralise and manage those resources better.
If a P IV is sitting 90% idle, it can definitely serve 5 users.
So 5 PCs with GigE running bittorrent. *LOTS* of servers, and lots of bandwidth, particularly if you are downloading from the local network.
From Wikipedia:
http://en.wikipedia.org/wiki/Phoenix,_Arizona
The city's automobile-dependent nature holds implications for greenhouse gas emissions. Although Phoenix is the sixth-largest city in the United States, its public transit system accounts for just one per cent of the passenger miles that New York City's does. The reason is that Phoenix's booming population has spread so far across the desert; greater Phoenix, whose population is a little more than twice that of Manhattan, covers more than two hundred times as much land.[4]
That isn't scaling up. Phoenix has a mere 1 million people in the city, with 3.7 million in the metropolitan region. That's a pretty small city, except that it is slightly more spread out. Problems tend not to show up until the first couple of decades of growth have been passed, when all the buffering of infrastructure provided by the original planning is used up. Planning can handle regular growth, not exponential.
Contrast with cities which have scaled up, like New York, or Mumbai.
That paper you link to is basically showing how development should NOT occur.
Except that security is relative and a risk management function. Secure against what threats? At what cost? Earlier we had buffer overflows. Now the holes have just moved up the stack.
Thanks.
Here
Turn off your mail client. Beiong unreachable and uninterruptable isn't bad.
IMAP. Use two IMAP servers, just copy the email over.
The cost of entry into the last mile is simple infrastructure cost, not regulatory. The problem is that the entity controlling the last mile now wants to regulate different types of traffic differently.
We are not speaking of control on total bandwidth either, we are speaking different classes of service within the same bandwidth class (not as in more money for more and/or guaranteed bandwidth, but as in "you can't use our competitors VoIP but you can use ours").
As long as the regulation requires hat all traffic of the same class be treated equally, there isn't a problem. The moment they start trying to offer differentiated services for different providers, there is a problem. They could always unbundle the local loop, and be banned from the content service business, whcih would be another way of enforcing net neutrality.
Your last mile is a monopoly, but usable by any service provider you choose, and you can choose the content providers you want because the service providers and last mile provider hold no stake in any of those.
As long as you don't travel, or use oil. Scaling high rises with mass transit based on electric power is far cheaper than getting resources to people who are spread out. Keep in mind that what you will lose out on is communication and travel.
Oh, and a few million immigrants from Asia looking for land could destroy your utopia quite easily. Just like the Europeans did to the native Americans.
Loose coupling leads to lesser bugs, and easier maintainability in the long run.
10. India - should really focus on sea mines- no one's gonna hump it over the himalayas to attack. Too many Yeti.
1962 - China
Pakistan - Kashmir (Google for Kargil, and Siachen), Rajasthan, Punjab.
I rather prefer big fucking nukes, and the willingness to use them. "Attack me, and I will reduce this planet to a slag heap" is a good deterrent to war. That does nothing to stop terrorists though.
I am not objecting to actual improvementz (which both KDE and GNOME have). What I am objecting to is the whole "one true windows interface" (minor nit), and the extremely tight coupling of the K* and G* components (major nit).
If I need one KDE app, or one GNOME app, I have to load a ton of libraries and waste precious memory (If I could afford it, I would have 16 GB of RAM here). That, to me, is painful. Just a Gtk app, not a big deal. QT app? No big deal.
But KDE and GNOME respond slowly, and spend time doing stuff which does not give me any benefit. As I keep getting reminded by developers from both sides, KDE and GNOME are meant to be complete environments and as such you should never need any application from the other at the same time.
So if I would rather use KDE's printing subsystem from a GNOME application, I have a ton of pain ahead.
I tend to shy away from such tightly coupled environments.
My work involves running very tighly integrated systems, but the components are completely decoupled. We have migrated across components, replacing large parts of the system architecture without resource usage changes,
Tight coupling is usually bad (IE, Windows, Exchange, Lotus Notes). Loose coupling with well defined protocols is good.
The Unix command line offers a well defined protocol -- STDIN, STDOUT, STDERR, and text streams (everything is a file would have been nicer if fully implemented, but it is still close enough). However, applications are not tighly integrated. You can use BSD tools, GNU tools, different shells and the system still works in more or less the same way.
When GNOME and KDE achieve that level of coupling, I'll take a look at using them again.
So you assumed that since I was talking about integration, I must necessarily be proposing bloatware?
Tight coupling is generally the problem. Loose coupling is good. As long as your applications are extremely loosely coupled, integration isn't an issue.
Ideally, there would be a application core,and the GUIs would merely be frontends over it. So it wouldn't matter which language you used, what DE you used, all your applications would be consistent in using the same files for configuration.
Oh, and I use Linux (and BSD) because of the way they let me decide on my environment (which hasn't changed in look and feel for about 6 years). Neither KDE nor GNOME satisfy those goals.
Of course, any single scientist should not be trusted. However, when multiple scientists get the same results using the same methodology, then those results can be considered a bit more trustworthy.
I mean, seriously, what's he going to do now?
Become a congressman. Or president.
People are starting to value their time more. In particular, they're starting to view that car trip as useable time.
Which is why man invented public transit. Now if the Americans would learn that and stop living a lifestyle which mandates cars...
No I didn't forget the Unix mantra.
Unix components are looselycoupled, and they let the user choose how to integrate them. I don't see the mention of loose coupling in the GP.
Oh, and the nature of the two main DEs essentially is that the integration part is left to the developers and not the users.
If the integration was done right, we would have a single file manager library, and two (or more) GUI wrappers on top of it. We don't have that kind of integration available in KDE/GNOME yet.