Tell me wise guy, who are you going to turn to after you spend a year in your basement writing the code to the next killer app and then the guy down the street, who couldn't code himself out of a wet paper back, copies your stuff, sells it for a million bucks, and leaves you crying at home?
Kill him the same way you killed all the lawyers?;-)
Where unenforceable means "enforceable until litigated otherwise". Your signature on a contract is prima facie evidence that you intend to abide by its terms. By the time it is found unenforceable, your employer has received a cease-and-desist order, you have spent thousands of dollars and weeks of time litigating, and you might even have liens against your house and car.
Only a moron signs a contract on the theory that it is unenforceable, and they deserve what they get.
If marketing and sales are that high a percentage of your costs, you're doomed.
To make money on infrastructure software, you have to convice hundreds of thousands of individual businessmen to buy a copy or two each. *They* control the purse strings, and if you don't convince them you die.
...you don't need to spend millions of dollars selling a free product to a bunch of geeks who already have it, and don't intend to buy support.
No shit. That's why they're going after businessmen who have money to burn and problems to solve.
Furthermore, they should take a lesson from microsoft, and have virtually zero support costs.
1. Microsoft spends tens of millions on Windows Update, support websites and documentation, and quality assurance to ward off the need for support.
2. Supported retail Win2k costs $200. Unsupported OEM Win2k costs $85. You do the math.
The worst of it though is that he feels that we, the developers out here writing the actual code, owe him something because of all this "promotion" that Caldera has done.
The single largest category of software is custom/customized business-automation apps. Getting Linux into businesses, and making them believe it is a valid enterprise platform, creates jobs for Linux developers.
Linux will be sold the same way all other platforms are sold: by the applications. When there are applications you need that run on linux, you get linux.
Yeah, applications like turnkey mail servers, heavy-duty DBMS clusters, network monitoring appliances, SMB/CIFS-compatible terabyte fileservers. Those are the sort of thing businesses are willing to burn money on, to the tune of billions of dollars. And the great thing is that they hate replacing a working system, so they'd rather come back year after year to keep that box running.
This is generally not regarded a security "hole"...
<megaphone>Sir, step away from the keyboard.</megaphone> Silently truncating passwords is a security hole of the first magnitude.
Suppose I have a password like this:
password weasel frycook barn tasteless thames gargoyle mascot
That is an extremely strong password that somebody might actually be able to remember. A flawed OS that truncates it to eight characters will use this:
password
Which turns an NSA-class password into a Gomer Pyle-class password.
they aren't simulating nuclear detonations for a fucking screensaver, they're simulating to design better (i.e. deadlier, more horrible) weapons.
Bzzt, wrong! The existing bombs are aging--tritium decaying, radioactives being contaminated by their decay products, explosives reacting with themselves--and they're trying to figure out how to keep them functional. The only solution is test explosions, and you have your choice of real tests or virtual tests. Congress has chosen virtual tests, and given LLNL the job of performing them.
they could be working on protein folding, doing advanced simulation on an alternative fuel engine, heck, they could leave it sitting there idly testing the reimann hypothesis,...
Bzzt, wrong! They're nuke scientists and engineers, not molecular chemists. Hiring people to do your proposed jobs would dwarf the cost of the supercomputer.
H bombs are big and scary, supposedly the only thing we want them for is deterrant, and aren't they already big enough and scary enough for that purpose?
Bzzt, wrong! More efficient can mean bigger, but it can also mean cleaner (i.e., less fallout) and cheaper. Cleaner is obviously good: a war would kill fewer people in less gruesome ways, and clean bombs are a better deterrent. Cheaper is also good, since all the bombs will have to be rebuilt from scratch in the fairly near future. (Don't give me any garbage about nuclear disarmament. It'll never happen, anybody who thinks it will is deluded.)
even if you don't think the US would ever use such a weapon (though it's the only nation in history that has) eventually knowledge spreads, and someone somewhere has a bigger bomb thanks to the cool supercomputer.
Bzzt, wrong! A big room full of people running mechanical adding machines can do the calculations for the basic plutonium bomb, which is how the first bombs were designed. A modest supercomputer and a few test explosions are enough to design most any bomb. The hard parts are (1) synthesizing and/or refining the fissile material is the hard part, (2) coming up with salaries for the physicists and engineers, and (3) developing delivery vehicles (ICBMs, long-range bombers) which dwarfs the cost of the bombs.
Besides, today's top supercomputer is tomorrow's video game CPU. Pretending that locking up a particular supercomputer can stop the work is just that: pretending.
It was upgraded. It was originally cooled using expendable solid nitrogen. Although the nitrogen did run out faster than planned, its limited lifetime was intentional. The new closed-cycle neon cooler is actually a major functional upgrade over the original design.
What is wrong with the existing 1.5 Mloc? Translating/rewriting is going to cost $250k-$2M, so the switchover must improve profits at least that much over its first couple of years of operation.
All serious (or non-broke) guitarists use tube amps because of the warm natural distortion of tubes and the ability to punch up the gain to get a very distinct distorted crunch. Solid state sounds flat compared to the tube.
True, but I wonder why they don't digitize the signal, apply any distortion curve they want, then convert back to analog. All the benefits of transistors, but you can dial in any distortion and other effects you can imagine.
But honestly, you could be bullshitting the entire thing, and about 4 people on slashdot would know it.
I'm one of the 4.;-) The description of how nonlinearity causes "interesting" intermodulation in complex signals is spot on. BTW, RF engineers deal with multi-signal intermodulation all the time (cell phone base stations, cable TV amplifiers, etc.)
Then one day, an electrical engineer came in and flat out proved to me with numbers, resistanace, etc, that you don't need anything more than 16 gauge wire for anything any amp we sold at best buy could put out into any pair of speakers we sold.
And even if it did make a difference, heavy speaker cable should only cost a little more than jumper cables. You could even make an (almost) impedance-matched 8.3 ohm coax by putting six 50 ohm coaxes in parallel, and it still wouldn't cost as much as the ridiculous audiophile cables.
If however "IT Guy" builds the server and installs *nix himself, "IT Guy" gets all the blame when something hardware or software goes wrong.
That's irrelevant*. What matters is labor cost and economies of scale. An IT guy costs $25-50 per hour. If he spends a day researching and ordering parts, assembling them, and testing the new machine, he has spent $200-400 of his employer's money. If one of the parts is incompatible or flaky, it can easily cost twice that. If you're just doing one machine, it can easily cost more than a turnkey machine.
(However it can be economical to build your own cluster. Research, procurement, and compatibility testing are amortized over the whole cluster. Assembly and functional testing costs per-machine, but is pretty cheap.)
* Unless the boss is an asshole. But if he is, everything will always be your fault anyway.
Is it really that hard to make hardware that actually works correctly any more?
We have an HP4MV at work that, when you are manually feeding 11x17 paper, will occassional grab an 8.5x11 sheet from the internal tray. When it discovers the sheet isn't long enough it says "64 ERR" on the display and locks up. So we looked up "64 ERR" in the manual and it says the printer has lost its mind and to power cycle it.
That's right, rather than fix the show-stopper mechanical flaw, or the show-stopper firmware flaw, HP just documented the hard reset.
HP engineering quality died long before the Compaq merger.
If you're having PROBLEMS with something, by all means upgrade, even if you don't think your OS is actually calling any code in the BIOS.
There's something called System Management Mode used by many modern motherboards, where the CPU is periodically interrupted and runs code from the BIOS. Motherboard designers use it for all kinds of stuff: emulating the keyboard controller, monitoring CPU temperature, etc. In general there's no way to know what SMM is used for; the OS just has to get out of the way and pray.
OS designers generally regard SMM as a dangerous kluge, and think that the tasks would be better done using a microcontroller integrated into the chipset. The problem is that (brain-damaged) motherboard designers don't see it that way...
There seems to be a general misconception that a product with a higher version number or newer release date will work better. Read the mfgr's description of what the product fixes.
Har har. If you believe that BIOS writers actually document the changes they make, I've got a bridge you can buy real cheap.
It impacts people who need to maintain the core scripts only.
All sites with more than a dozen or so users need to be able to customize the scripts, or at least easily read them to figure out what the hell is going on. That most sysadmins are novices, and work at smallish sites, dictates that the scripts should be written in a friendly language.
In the event that an administrator needs to modify any of these scripts, the important thing is that the widest possible array of system administrators are able to.
I agree. I'm just taking the wider view that computers should be for *all* people with a modicum of skill, not just veterans of the Unix wars. So languages for common automation tasks should be chosen solely for ease of use by novices. As VB and especially Python have proven, it is possible for a language to be friendly to novices *and* a decent tool for wizards.
What they are doing is making sure that a default install of FreeBSD doesn't require a particular version of perl to be installed.
Are you replying to the post I wrote? My two points were 1) that a modern operating system *should* rely on a particular version of a full-featured scripting language, and 2) the interpreter for that language should not be shared with applications (to prevent the upgrade problem).
This is exactly what FreeBSD offers you. After you've installed it. Go add Python.
Try reading what I wrote. At that point it's too late: the core is written in nasty old sh and hardcoded C. No amount of installing packages later can fix that fact.
In contrast to RedHat Linux which is wedded inseperably to Python 1.5.2, which has been out of data for about a millennia.
Exactly. Red Hat made the same mistake as FreeBSD: they needed a good language for scripting the core OS, and they stupidly used the same package as user applications. And now, predictably, the user applications cannot be upgraded because it would break the really important stuff. The solution is to break that dependency: make the applications and the core depend on different executables.
The FreeBSD solution is to move everything to depend on the/bin/sh executable: it's so vile and useless that nobody sane would **ever** use it for a significant application. Since no applications use it, there can be no conflict. This is self-evidently stupid.
The right solution is to pick a good language (call it "Foo"), put together a stripped-down interpreter for it, and put that interpreter it its own files. E.g.,/usr/bin/system-foo. This has lots of benefits:
All the "kitchen sink" libraries have been ripped out, so it doesn't take up much space.
It is used for a small set of tasks that rarely change, so there is no need to track the latest upgrades, just the critical bugfixes.
It has completely different file names, so applications will never use it by mistake.
Application packages use different file names, so they can be upgraded at will. The core won't notice.
Sysadmins and core maintainers won't waste time and sanity dealing with the nasty syntax and limitations of sh. They'll work in Foo, a nice modern language.
Let's all install two different versions of perl on our boxes. One for the system, and one for the user. I've dealt with this hell on HP-UX 10.20 (which ships with perl 4) and I don't like it much.
Maybe I didn't make that clear: the two Perls should be *completely* separate./usr/bin/system-perl should come from its own dedicated package, a package that the core maintainers guarantee does not conflict with anything else. It should not be a standard package that has been kluged to install in an odd location. You should be able to upgrade user Perl with absolute confidence that system Perl will not break, and vice versa. The only thing they should share is a name and a syntax.
I applaud FreeBSD for finally starting to do what NetBSD has done since the beginning: Install a base OS and let the user decide what else they want or need.
But they haven't! They are ramming C and sh down the average sysadmin's throat, without the slightest thought about what is appropriate for that sysadmin.
In the real world, most sysadmin labor hours are spent on servers and workstations running powerful, modern hardware. And what they need are transparent, diagnosable systems. When things go wrong, or when they have a complex task to accomplish on a short schedule, they need to be able to reach inside the system and extend it. Hard coding system logic into C programs is extremely counterproductive, and sh is so limited and restrictive that you have to jump through all sorts of ridiculous hoops to accomplish the simplest tasks. What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
It is a security risk when it's so tempting to use it, but it's so vulnerable to exploits.
Good point. telnetd ought to be fixed so it only runs the program specified on the command line, the stock inetd config should specify/bin/false as the program to run, and the documentation should discourage use with insecure programs.
Besides, the current state of affairs is not the Unix Way: telnetd should be an autonegotiating filter for interactive terminals, and nothing more. It should never have known anything about logins or shells in the first place.
Funny, I almost mentioned netcat. But AFAIK Windows doesn't have a plain socket client, just a telnet client. I've had some very bad results when plain socket servers try to interpret a telnet client's handshaking data.
And, as another poster pointed out, telnet and (to a lesser extent) ftp have to be next on the chopping block.
I disagree. FTP is a fine way to serve files to anonymous clients. A lot of data traffic simply doesn't benefit (much) from security. Unless you are going to replace it with HTTP over SSL and institute a person-to-person key fingerprint distribution process, you might as well keep using FTP.
As for telnet, using it to run login shells is idiocy, but it's the only standardized way to run interactive services. It comes disabled by default, so including it is not a security risk. And when you someday need a little interactive network program *right now*, it's damn convenient. E.g., if you needed to stick a load monitor on your database server, just write a little program that talks on standard input and output, and tell telnet to use it instead of a shell. Instant results, little risk of breaking anything, and any client can access it.
But not to get into some religious war, it's nice to see that FreeBSD will leave the choice to us.
Yeah, you get your choice of C or sh, which are bletcherous languages for system administration. To diagnose/repair a broken C program, you have to be a skilled programmer with a lot of time on your hands. No instant patches/changes are possible. If that little system automation utility written in C breaks in production, the typical business should expect hours of downtime.
Or there's sh, which you can fix instantly, but you have to learn yet another toy syntax, a syntax that is highly restrictive when it comes to real programming work.
And what is the justification for this? So it'll fit better on ancient, obsolete harware. Great, my sysadmins will piss away thousands of dollars in labor (and possibly millions in downtime) dealing with shitty languages, because it will save the hundreds of dollars it would cost to replace that old 486 router.
Equally idiotic are the arguments that using Perl for the core makes it difficult to upgrade Perl. That's because they should be different Perls. For core system stuff, there should be/usr/bin/system-perl, an old, stable, stripped-down Perl that rarely changes. Applications should use/usr/bin/perl, which can be upgraded as needed to make the latest apps run.
Morons. Hardware cost is almost always irrelevant. Dependency conflicts almost always mean you need to fork. But no, we have to change the admins to suit the machine...
Couldn't the RF Light manufacturer just shield the light fixtures e.g. a Microwave Oven?
Microwave ovens aren't shielded any better. (In fact, the RF lamps are nothing more than microwave ovens that heat a quartz bulb with a tiny bit of sulfur in it. The sulfur gets hot, vaporizes, and glows.) The problem is that the magnetrons used in ovens and lamps don't have very good frequency control. Their spectral peak could land anywhere inside the ISM band at 2.4 GHz. Wi-Fi (802.11b) was designed to work around ovens by hopping between a bunch of narrow little bands, the theory being that if you have several microwave ovens in the building there will still be zones that are free of interference.
That works fine for most buildings. There are only perhaps a dozen ovens at most, and they only run for a few minutes at a time. But there could be hundreds of RF lamps, and they could operate 24X7 in a warehouse environment. The lamps could potentially make the RF environment orders of magnitude more hostile to data service, so that's why people are in a lather over it.
The "Heisenburg [sic] uncertainty prinicple [sic]" is not a misconception arising from inexact experimental tools; it has nothing to do with the quality of experimental means.
Indeed. That American Spectator article linked above is junk science at its worst. I considered writing a detailed criticism of the article, but why bother? It is crystal clear that the guy has only a superficial and often-incorrect knowledge of the theories he is trying to debunk. E.g., he ridicules the correspondence principle as if it were a law of physics, when it is actually a combination of 1) an acid test used to rule out incorrect quantum theories, and 2) a demonstration that quantum mechanics can produce the world that is observed at the scale of everyday life.
What your talking about now is whenever someone has one of these devices going, it will have the effect of dropping the station your hearing, watching, or even talking to, under the noise.
Do you have a link power budget analysis to support this, or are you talking out of your ass?
Oh, and if your interested in this UWB stuff, then don't even think about security, the only way to keep you stuff partially secure would be Spread Spectrum, which needs to be managed on a set of frequencies.
Baloney. No modulation scheme provides any security whatsoever. If you want security, you have to use cryptography.
Slashdot Mirror
Only a moron signs a contract on the theory that it is unenforceable, and they deserve what they get.
2. Supported retail Win2k costs $200. Unsupported OEM Win2k costs $85. You do the math.
The single largest category of software is custom/customized business-automation apps. Getting Linux into businesses, and making them believe it is a valid enterprise platform, creates jobs for Linux developers. Yeah, applications like turnkey mail servers, heavy-duty DBMS clusters, network monitoring appliances, SMB/CIFS-compatible terabyte fileservers. Those are the sort of thing businesses are willing to burn money on, to the tune of billions of dollars. And the great thing is that they hate replacing a working system, so they'd rather come back year after year to keep that box running.Suppose I have a password like this:
That is an extremely strong password that somebody might actually be able to remember. A flawed OS that truncates it to eight characters will use this: Which turns an NSA-class password into a Gomer Pyle-class password.Besides, today's top supercomputer is tomorrow's video game CPU. Pretending that locking up a particular supercomputer can stop the work is just that: pretending.
It was upgraded. It was originally cooled using expendable solid nitrogen. Although the nitrogen did run out faster than planned, its limited lifetime was intentional. The new closed-cycle neon cooler is actually a major functional upgrade over the original design.
What is wrong with the existing 1.5 Mloc? Translating/rewriting is going to cost $250k-$2M, so the switchover must improve profits at least that much over its first couple of years of operation.
(However it can be economical to build your own cluster. Research, procurement, and compatibility testing are amortized over the whole cluster. Assembly and functional testing costs per-machine, but is pretty cheap.)
* Unless the boss is an asshole. But if he is, everything will always be your fault anyway.
That's right, rather than fix the show-stopper mechanical flaw, or the show-stopper firmware flaw, HP just documented the hard reset.
HP engineering quality died long before the Compaq merger.
OS designers generally regard SMM as a dangerous kluge, and think that the tasks would be better done using a microcontroller integrated into the chipset. The problem is that (brain-damaged) motherboard designers don't see it that way...
The FreeBSD solution is to move everything to depend on the /bin/sh executable: it's so vile and useless that nobody sane would **ever** use it for a significant application. Since no applications use it, there can be no conflict. This is self-evidently stupid.
The right solution is to pick a good language (call it "Foo"), put together a stripped-down interpreter for it, and put that interpreter it its own files. E.g., /usr/bin/system-foo. This has lots of benefits:
In the real world, most sysadmin labor hours are spent on servers and workstations running powerful, modern hardware. And what they need are transparent, diagnosable systems. When things go wrong, or when they have a complex task to accomplish on a short schedule, they need to be able to reach inside the system and extend it. Hard coding system logic into C programs is extremely counterproductive, and sh is so limited and restrictive that you have to jump through all sorts of ridiculous hoops to accomplish the simplest tasks. What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
Besides, the current state of affairs is not the Unix Way: telnetd should be an autonegotiating filter for interactive terminals, and nothing more. It should never have known anything about logins or shells in the first place.
Funny, I almost mentioned netcat. But AFAIK Windows doesn't have a plain socket client, just a telnet client. I've had some very bad results when plain socket servers try to interpret a telnet client's handshaking data.
As for telnet, using it to run login shells is idiocy, but it's the only standardized way to run interactive services. It comes disabled by default, so including it is not a security risk. And when you someday need a little interactive network program *right now*, it's damn convenient. E.g., if you needed to stick a load monitor on your database server, just write a little program that talks on standard input and output, and tell telnet to use it instead of a shell. Instant results, little risk of breaking anything, and any client can access it.
Or there's sh, which you can fix instantly, but you have to learn yet another toy syntax, a syntax that is highly restrictive when it comes to real programming work.
And what is the justification for this? So it'll fit better on ancient, obsolete harware. Great, my sysadmins will piss away thousands of dollars in labor (and possibly millions in downtime) dealing with shitty languages, because it will save the hundreds of dollars it would cost to replace that old 486 router.
Equally idiotic are the arguments that using Perl for the core makes it difficult to upgrade Perl. That's because they should be different Perls. For core system stuff, there should be /usr/bin/system-perl, an old, stable, stripped-down Perl that rarely changes. Applications should use /usr/bin/perl, which can be upgraded as needed to make the latest apps run.
Morons. Hardware cost is almost always irrelevant. Dependency conflicts almost always mean you need to fork. But no, we have to change the admins to suit the machine...
That works fine for most buildings. There are only perhaps a dozen ovens at most, and they only run for a few minutes at a time. But there could be hundreds of RF lamps, and they could operate 24X7 in a warehouse environment. The lamps could potentially make the RF environment orders of magnitude more hostile to data service, so that's why people are in a lather over it.
This sounds like antique fire extinguisher bottles: thin glass "grenades" full of water or other chemicals that were tossed at fires.