Try playing a mp3 off an smb share without mounting the smb share. Not allowed.
Care to explain why should it be allowed? Access to remote filesystems should be delegated to the kernel. And yes, Linux can only access mounted filesystems. It has never been a problem before...
Moore's law is pretty much an exception to normal law.
Now, here's a mindtwister for you. What *if* Moore's law is not the exception but the rule for scientific development? If you look on advances per century, scientific advance seems clearly exponential...
Plone products -- borrowing from Plone and other Plone Products with Plone borrowing from Zope and Zope borrowing from Python -- is just about an ideal example of how to strengthen multiple projects while still getting the narrowly focused service you want that can be tweaked at will. Others can come up with non-Plone examples that they favor, so don't take this as a PHP vs. Plone rant. It's a world vs. PHP rant!:}
Oh, Plone is great if you just want to quickly deploy a CMS. It's H-E-L-L if you need to develop on top of it. About the absolutely worst software documentation I've ever seen in my life.
You'll have to ask yourself: Which is easier to find? Money or workforce? Given enough money, you're guaranteed to amass a workforce. The reverse isn't true. In fact, find yourself with 100% work force and no cash, and the 100% will reach 0 in a couple of days.
Priorities in generosity are wrong. I think health is probably more important than computers.
Once these countries have dealt with disease, food, debt, etc then what OS they have becomes a bit more of an issue.
While I do agree that countries dealing with famine won't give a rat's ass about technology, it's important to understand that only (more) advanced technology can support raising worldwide living standards to western levels. You could pledge worldwide XIX century resources to solving current African problems, and it would be insufficient. So, priorities may not be 100% correct, but technology development should be the topmost priority. Undoubtedly.
The Unix filesystem hierarchy has network maintenance taken into account. Having program 'bundles' may be great for a single workstation, but is hell for a network-wide system. The FHS explains this much better than I could, so please read the rationale there.
Personally, I see this like going back to the DOS days. Linux/BSD have been dealing with shared libs in pretty sane ways. Although rpm is sometimes a pain in the butt, Debian's package system and Gentoo's Portage prove that dealing with dependencies automatically is feasible and confortable.
And, anyhow, for special cases, you can always drop apps into/opt and get the equivalent of a bundle. Oracle does this, vmware does this, as there are countless other cases.
The newer Sun boxes even have LOM (lights out management) that lets me power cycle the box remotely right from the console. Try doing that on an Intel box (without using an APC masterswitch).
IBM's xServers (intel line) all have LOM. They use RS-485, which makes it a pain to find proper cabling (other than from IBM), but otherwise its an excellent solution.
Besides zSeries and S/390s, you have the new xSeries interconnectable servers -- virtualized servers composed of up to four boxes. A kind of poor man's mainframe. And don't forget virtual linux installs running under AIX on any mainframe.
That's not the point. Calling a person a resource dehumanizes them. Of course you aren't going to keep someone around just because they need a paycheck, but that doesn't mean you should axe them the moment it's convenient. They've shown some level of commitment and they know something about your business. The least you can do is give them some warning. In addition, your business may be cyclical. Keeping them around may be cheaper and safer than hiring new people when demand picks up.
Understand this: People are resources, from the POV of a company manager. All a manager sees are the company numbers. You cite a couple good business reasons to keep unprofitable employees: Cyclic economies and domain know-how. I can add employee morale to the equation. However, if it doesn't make business sense, employees get axed. Don't doubt it.
Put yourself in the shoes of a top manager, who must hold the company through rough times, or from a middle manager who must produce the required bottom-line. The solution to the equation is rather simple. There is no loyalty from the company to you.
By definition the Euro/US rate was 1:1 when the euro was first implemented.
OMG, so much US-centrism! The euro rate has nothing whatsoever to do with the USD value. This is not Brazil, you know. It'd be stupid for an economy larger than the US to admit subservience to the USD when launching a competing international currency. A bit of history is badly needed here:
The Euro, by definition, rated 1:1 to the ECU, the Europen Currency Unit, from the launch of the Euro in 31st Dec.'98. Euro to local currency exchange rates were frozen at the rates the currencies presented against the ECU.
From then on, due to the exchange rate freeze, countries in the Economic and Monetary Union were dealing in Euros, even if the physical coins and bills were introduced only in January, 2001. Accounting practices were converted to euros during this transition period.
The ECU has no correlation to the USD. It was introduced in the late 70's, as a mechanism to pass currency exchange control to the European Central Bank. The ECB defined bands of variation (usually +/- 2.5%) of local currencies against the ECU, and coordinated actions of national banks to defend local currency rates, or vary the global ECU rate by varying all the other currencies. It is in fact a predecessor to the euro, as the Euro is an ECU with zero local fluctuation (which enables direct actions by the ECB, instead of just coordination). The ECU initial rate was just an average of the different currencies, weighted by their respective GDP.
On another note, you really should take note of the low dollar value. The dollar has devalued ever since the US started the Iraq war. It has devalued against most other world currencies, so this is not a fluctuation, but more of an acknowledged way of dealing with large and increasing external debt. Large deficit (and debt) is the single reason that will force the US out of Iraq in a couple of years more.
I also don't believe the US isn't going bankrupt. But they're doing quite a good job looking like a bankrupt country. The Euro-Dollar rate is now at 1.36. Euro-dollar was almost at parity level on 2000 and I remember seeing the rate at ~0.80. We're talking a 70% devaluation of American currency, to cope with external debt.
The GUI, in the user sense, is an afterthought. You have to go to the command line to configure and/or adjust and/or install many things. Now, I don't really care a bit about this, but most users will want to avoid command line stuff. Lock out many users with this kind of esoterica, and you've made an error, IMHO. One of the places an OS gets strength from is a broad userbase in the sense of "not one demographic" (such as only technical types.) If Linux doesn't offer ease of use, then they'll go where they can get it - Windows, OS X. And we lose. Sure, some of you just chortle at the very thought, but I truly think you're being shortsighted when you do.
It *is* an afterthought. Naturally. And this is a good thing.
Your complaint is valid in the sense that there are many tasks that can't be done through the GUI, but only through the lower level (design-wise) command line interface. That's the result of being an incomplete system. This is very different from being the result of an ill-designed system.
Linux has a pretty poor cache and swap system, combined with zero user level control over cache and swap. As a result, over time, the OS runs slower, and s l o w e r and s... l.... o..... w...... r....... until you restart, and then it's back to being fairly snappy until it fills up memory again with things it shouldn't be caching, and then it begins to swap again, and the slowdown process starts over again. Although Linux will run just about forever if you let it, you'll get considerably higher performance in a big-memory machine or server if you reboot when your memory fills up with cached-crappola.
Bullshit. The behaviour you describe is, in fact, what I associate to a windows system. Our mail servers run for months at a time without stopping, receiving huge amounts of mail (an order of magnitude around a couple hundred thousand messages per day) and never ever show the behaviour you describe. And these are boxes running 2.4 kernels, performing disk-intensive tasks. The 2.6 branch has even better cache systems.
Granted, servers rarely, if ever, swap out. But my desktop has been linux-only for some years now and I have never observed the behaviour you describe.
The basic Unix I/O model is that of byte streams flowing around the system, and in and out of devices. Unfortunately, this model really only applies to tape drives; most devices have to be addressed first (such as a disk block number), and then read or written in discrete chunks (blocks, packets).
I see no problem. The Unix I/O model is a level lower than the one you describe. Disks can be treated as tape drives, read one byte at a time without seeking ability. The fact they support seeking does not prove that the model is wrong.
The I/O model would be wrong if it assumed all devices support seeking when some of them don't -- namely pipes and network streams.
why can't installing a program on Linux be like installing a program on OSX? Copy an application bundle to the application directory. Done.
I never got this admiration OSX users have for having each app on its own directory. How do you handle dependencies? Apps are really just the leafs of an entire tree of software packages installed on my system. Out of all the packages on my world file, perhaps 10% are applications I regularly use. The rest are libraries, stuff like libjpeg, libxml or libzip, used by many of the apps. Do you have a dir per library? Isn't that a terrible mess?
I suppose it depends on what you use the machine for. Linux isn't ready for the desktop so I don't run a GUI on it. Thus I really have no latency issues running maild/httpd/sshd/etcd.
:-)))) I'd moderate you funny if I hadn't commented yet. My desktop is linux for three years now.
Hint: Don't wait until the media says linux is desktop-ready.
Exactly. This is happening with a lot of free software lately, namely the Linux kernel... I used to keep up-to-date on the kernel just because it was always getting better.
It's natural, and it's a good thing. OSS, when it fullfills the needs of most users just stabilizes. It doesn't enter the bloat cycle to promote upgrades.
2.4.x has been rock solid for me and 2.6.x just doesn't offer anything to me that makes me compelled to move to it (in fact I had issues w/my ethernet cards working under it).
If you have very large numbers of processes, the O(1) scheduler alone is enough of a reason. For personal use, I find the low latency quite a good reason to change.
Apache 1.3.x has been absolutely fine and continues to update via apt-get/aptitude. Why should I bother with 2.0.x? Give me one reason why this needs to be an issue? PHP people think that PHP runs better under 1.3.x and Apache continues to develop that version. I don't see the problem.
Filtering the output through various modules was the killer reason for my switch. With apache2, you can get content produced by mod_php compressed afterwards by mod_deflate. mod_deflate is much much better than the solutions integrated in PHP (bug-less content negotiation).
As for stability, the PHP team assumes the only problem is with threaded models. Just opt for a prefork MPM and you're done.
I see no reason to use client or server-side products that analyze the mail content, when this slows down mail service and reliability.
None of the modern content scanners slow down mail delivery, unless you try to run them on a underpowered hand-me-down PC.
We process 60 messages per second, on average, on normal weekday. Peaks go well above that value. Anything, even the lightest processing of a mail message, is felt on the servers load. I can certainly agree with the parent post.
Borderline rejection saves lots of resources, because it leaves the grunt work of dealing with a failed delivery to the source server. Its not just content processing. It is also delivery failure notification processing.
"Legitimacy" in this case is in the eye of the administrators of the RBL, not in the eye of the administrator using the RBL on his mail server.
Untrue. Legitimacy is in the rules defined for the RBL. Spamcop follows a public rating procedure. Idem for ORDB open relay RBL. When using these, the sysadmin is setting a rule. Hosts which follow a pattern that gets them flagged by either of these are rejected. It is easy to get out of the lists, and senders are notified of the cause.
Borderline RBLs are very very useful on high traffic mail servers. You stop the mail *before* it gets in. No wasted CPU cycles, and you don't need to send a non-delivery notification. relays.ordb.org, at least, is a must. I'm quite happy with bl.spamcop.net also (It's a kind of spamAssassin oriented to IP address past behaviour).
Slashdot Mirror
You'll have to ask yourself: Which is easier to find? Money or workforce? Given enough money, you're guaranteed to amass a workforce. The reverse isn't true. In fact, find yourself with 100% work force and no cash, and the 100% will reach 0 in a couple of days.
- Microsoft sells today an order of magnitude more units of Office (with minimal marginal production costs)
- MSOffice has long achieved maturity, allowing a large reduction in development manpower
- As computers get more powerful, software is easier to write
Those are very large factors, with almost no environment factors denying their effect.Personally, I see this like going back to the DOS days. Linux/BSD have been dealing with shared libs in pretty sane ways. Although rpm is sometimes a pain in the butt, Debian's package system and Gentoo's Portage prove that dealing with dependencies automatically is feasible and confortable.
And, anyhow, for special cases, you can always drop apps into /opt and get the equivalent of a bundle. Oracle does this, vmware does this, as there are countless other cases.
Besides zSeries and S/390s, you have the new xSeries interconnectable servers -- virtualized servers composed of up to four boxes. A kind of poor man's mainframe. And don't forget virtual linux installs running under AIX on any mainframe.
Put yourself in the shoes of a top manager, who must hold the company through rough times, or from a middle manager who must produce the required bottom-line. The solution to the equation is rather simple. There is no loyalty from the company to you.
So, yes you're right. It's your windows background...
Portuguese has so many different sounds you can say anything is based off it...
The Euro, by definition, rated 1:1 to the ECU, the Europen Currency Unit, from the launch of the Euro in 31st Dec.'98. Euro to local currency exchange rates were frozen at the rates the currencies presented against the ECU.
From then on, due to the exchange rate freeze, countries in the Economic and Monetary Union were dealing in Euros, even if the physical coins and bills were introduced only in January, 2001. Accounting practices were converted to euros during this transition period.
The ECU has no correlation to the USD. It was introduced in the late 70's, as a mechanism to pass currency exchange control to the European Central Bank. The ECB defined bands of variation (usually +/- 2.5%) of local currencies against the ECU, and coordinated actions of national banks to defend local currency rates, or vary the global ECU rate by varying all the other currencies. It is in fact a predecessor to the euro, as the Euro is an ECU with zero local fluctuation (which enables direct actions by the ECB, instead of just coordination). The ECU initial rate was just an average of the different currencies, weighted by their respective GDP.
On another note, you really should take note of the low dollar value. The dollar has devalued ever since the US started the Iraq war. It has devalued against most other world currencies, so this is not a fluctuation, but more of an acknowledged way of dealing with large and increasing external debt. Large deficit (and debt) is the single reason that will force the US out of Iraq in a couple of years more.
I also don't believe the US isn't going bankrupt. But they're doing quite a good job looking like a bankrupt country. The Euro-Dollar rate is now at 1.36. Euro-dollar was almost at parity level on 2000 and I remember seeing the rate at ~0.80. We're talking a 70% devaluation of American currency, to cope with external debt.
Your complaint is valid in the sense that there are many tasks that can't be done through the GUI, but only through the lower level (design-wise) command line interface. That's the result of being an incomplete system. This is very different from being the result of an ill-designed system.
Granted, servers rarely, if ever, swap out. But my desktop has been linux-only for some years now and I have never observed the behaviour you describe.
IBM is doing this, at the hardware level, with X-Architecture.
The I/O model would be wrong if it assumed all devices support seeking when some of them don't -- namely pipes and network streams.
Hint: Don't wait until the media says linux is desktop-ready.
As for stability, the PHP team assumes the only problem is with threaded models. Just opt for a prefork MPM and you're done.
Borderline rejection saves lots of resources, because it leaves the grunt work of dealing with a failed delivery to the source server. Its not just content processing. It is also delivery failure notification processing.
Untrue. Legitimacy is in the rules defined for the RBL. Spamcop follows a public rating procedure. Idem for ORDB open relay RBL. When using these, the sysadmin is setting a rule. Hosts which follow a pattern that gets them flagged by either of these are rejected. It is easy to get out of the lists, and senders are notified of the cause.Borderline RBLs are very very useful on high traffic mail servers. You stop the mail *before* it gets in. No wasted CPU cycles, and you don't need to send a non-delivery notification. relays.ordb.org, at least, is a must. I'm quite happy with bl.spamcop.net also (It's a kind of spamAssassin oriented to IP address past behaviour).