If you are programming the solution to a known problem, your usual accounting/stock control/etc applications, then it's just engineering. You have room for adding your personal touch to it, just like any engineer have, but it's not quite art.
Other programs, like new problems, new algorithms for old problems or programs in which your "personal touch" is a large part of how the program works, well, *that* is art.
> There is no documentation anywhere to tell you
> that you need to read the ata(4) man page to
> find out about the disk driver
First, the handbook will clearly indicate that ata is the driver for ATA devices (duh!). Second, it shows so on the boot messages, which can be reviewed with dmesg(1) if needed. You want to know about udma on your drives, right?
/d/home/dcs$ apropos udma drive
(enourmous list of various drivers, among which:)
ata(4), acd(4), ad(4), afd(4), ast(4) - Generic ATA/ATAPI disk controller driver
The list is rather big, but if you failed to avail yourself of both handbook and boot messages to find out what driver is being used...
Next, you wanted to know about vga modes on the console, right?
/d/home/dcs$ apropos vga console
loadfont(1) - is used to load fonts into EGA or VGA boards for use by the 'pcvt'
video driver
vga(4) - generic video card interface
kbdcontrol(1) - a utility for manipulating the syscons console driver
moused(8) - pass mouse data to the console driver
pcvt(4), vt(4) - PC console virtual screen system
speaker(4), spkr(4) - console speaker device driver
syscons(4), sc(4) - the console driver
vidcontrol(1) - a utility for manipulating the syscons console driver
Alternatively, he could adopt a more decentralized model where, with the help of version control and source repository management software, people who have shown a good track record in presenting patches would be allowed direct access to the source in development and be able to check in the changes needed themselves, as well as serving as proxy for other people to submit their changes.
But only the BSD people adopt such a closed model, right?
I myself can find more than 100 people in my mailbox alone!
More to the point, if there were just "100 people", IBM would just have stuck to there "not supported" excuse and that would have been it.
If they decided finally to produce a patch even though FreeBSD is "not supported" and is not part of IBM strategy in any way (Linux was affected too at first, but they produced the patch pretty fast once IBM Linux people got in touch with IBM Thinkpad people), it's because they effectively felt the bite in their pockets.
From what I have seen on the few mailing lists I subscribe to every time this issue came up, that doesn't surprise me at all.
Not that I, personally, intend to buy a Thinkpad any time soon. It was once considered by many FreeBSDers among the best laptops in the market, but Open Source depends on standards, and IBM's failure to follow standards is too glaring to ignore.
I think the _real_ fear people have is the idea that the clone will have the same memories as the original, pretty much like what happens in "6th Day". This, coupled with the notion that a clone will have the same age as the original.
For this reason I believe that while opposing fanatics will always exist, most people will end up thinking there is no big deal about it, because their real fear had nothing to do with cloning in first place.
Actually, I think you can. They have visiting days or something like that, and I think there are periods where one can actually catch a demonstration ride.
Of course, there isn't much of a point in catching a train that only stop at one station.:-)
Japan is already too advanced in their own maglev project. They already have a good section of it, on which they have been conducting experiments, and I find it difficult anything China starts doing _now_ will get finished before the Tokyo-Osaka line.
If you can't distinguish the real thing from the fake, then make it a requirement to have all the software/data needed to produce the fake from the scratch. Just like it's already a requirement to be able to prove all actors in a porn movie are above 18.
This argument of feasibility of prosecution is wrong.
First, you are all talking about "virtual indistinguishable from real." Well, fine. Go after *THAT*. But the issue here is virtual *clearly* distinguishable from real. You are proposing to outlaw *THAT* just cover the former case?
Second, if the former case becomes real, just make it a law keeping proof of the "making of". Ie, if you sell something indistinguishable from the real thing, you have to be able to provide the program and the data you used producing it. This is *NOT* undue burden. This kind of thing exists already. If you make a porn movie, you have to keep proof that all actors were of legal age. Financial institutions have to keep all sorts of data proving they did things legally.
Don't make me laugh! What's the capacity of the power supply unit of your super-powerful computer? 250W? 300W? That's the *maximum*, but never mind that, let's assume you are actually using that much power. That's 3 lamps. 5 of the very weak 60W lamps.
How much does your microwave uses? 500W? 750? What about your toaster? 1000W? 1500W? Electrical heater: 2000W? 2500W? Refrigerator, freezer, electrical boiler, water heater, hair drier, TV... your computer doesn't even make a dent on what you are paying (and consuming).
There are two reasons for the California problem:
1) The power companies put all new power station development on hold until the deregulation was through, to see what kind of playing field they would have. The deregulation was long, and the power consumption skyrocketed all through it.
2) The power companies were incompetent, resulting in very bad deals and power consumption predictions.
A multithreaded IP stack doesn't make it faster. As a matter of fact, it's necessarily slower than it would be possible with a non-multithreaded stack, all other things being equal.
What it DOES make for is for greater performance on SMP systems and with multiple NICs.
FreeBSD is reputed to have a faster IP stack, as far as UP systems go. I don't know whether that's true or not, but many ex-Linux FreeBSD users do claim so. The huge (and record) throughput on ftp.freesoftware.com (formely ftp.cdrom.com) is sometimes cited as proof.
As for Windows, I don't know about 2000, but NT does have a multithreaded IP stack, one of the reasons why it beat the hell out of Linux (and FreeBSD) on a famous benchmark.
Still, real world throughput is likely to depend much more heavily on simple things like the accept filters or the kqueue interface than on the IP stack speed.
And while all the above might be true or not, it's not really the reason why heavy weights chose FreeBSD. What makes FreeBSD special for many is it's capability to handle heavy loads gracefully.
SMP-safe? Sure FreeBSD's TCP is SMP-safe. You can run it on SMP without ever running into a single problem. Maybe you wanted to say something else?
I must confess I never even heard of ECN and SACK, which doesn't really mean much. We do care a lot about standards, though. As it should be obvious to anyone with the least historical knowledge, in the absence of actual contact with the current developer community.
Benchmarks. Yeah, we probably should optimize for benchmarks, like developing an ultrafast getpid() system call, so benchmarks which use that as a "null" system call show faster results. Instead, we spend time uselessly on optimizing for real world use. Sigh. We are so foolish! If we aimed at being good on paper instead of being good on practice, we could grab a much larger market share in exchange for a few really heavy sites that absolutely need us!
UFS is over 10 years old. Well, softupdates isn't, but that's beside the point. UFS still kick ass. There is a whole class of ex-Linux FreeBSD users whose main concern was the superiority of UFS over ext2.
As for Linux UFS, last I heard it was "use at your own risk", and not particularly fast at it.
Sure enough, Reiserfs, Tux2, JFS, XFS and ext3 will, eventually, all kick ass. Well, scratch JFS off that list, since it was based on a really slow version. Heck, Reiserfs is kicking ass now, as a matter of fact, despite some claims that it is infringing on some patents.
How can "OpenBSD rules" possibly be off-topic? It's entirely on-topic for this story, and since this *is* an OpenBSD story, it can't even be called a flamebait (it insults no one else, and certainly not the OpenBSD users).
Slashdot Mirror
If you are programming the solution to a known problem, your usual accounting/stock control/etc applications, then it's just engineering. You have room for adding your personal touch to it, just like any engineer have, but it's not quite art.
Other programs, like new problems, new algorithms for old problems or programs in which your "personal touch" is a large part of how the program works, well, *that* is art.
> There is no documentation anywhere to tell you
> that you need to read the ata(4) man page to
> find out about the disk driver
First, the handbook will clearly indicate that ata is the driver for ATA devices (duh!). Second, it shows so on the boot messages, which can be reviewed with dmesg(1) if needed. You want to know about udma on your drives, right?
/d/home/dcs$ apropos udma drive
(enourmous list of various drivers, among which:)
ata(4), acd(4), ad(4), afd(4), ast(4) - Generic ATA/ATAPI disk controller driver
The list is rather big, but if you failed to avail yourself of both handbook and boot messages to find out what driver is being used...
Next, you wanted to know about vga modes on the console, right?
/d/home/dcs$ apropos vga console
loadfont(1) - is used to load fonts into EGA or VGA boards for use by the 'pcvt'
video driver
vga(4) - generic video card interface
kbdcontrol(1) - a utility for manipulating the syscons console driver
moused(8) - pass mouse data to the console driver
pcvt(4), vt(4) - PC console virtual screen system
speaker(4), spkr(4) - console speaker device driver
syscons(4), sc(4) - the console driver
vidcontrol(1) - a utility for manipulating the syscons console driver
Which is pretty much what you want.
You should have used man(1) and apropos(1). Sure, they don't work on Linux, but they *do* work on FreeBSD.
But only the BSD people adopt such a closed model, right?
ROFLOL!
I myself can find more than 100 people in my mailbox alone!
More to the point, if there were just "100 people", IBM would just have stuck to there "not supported" excuse and that would have been it.
If they decided finally to produce a patch even though FreeBSD is "not supported" and is not part of IBM strategy in any way (Linux was affected too at first, but they produced the patch pretty fast once IBM Linux people got in touch with IBM Thinkpad people), it's because they effectively felt the bite in their pockets.
From what I have seen on the few mailing lists I subscribe to every time this issue came up, that doesn't surprise me at all.
Not that I, personally, intend to buy a Thinkpad any time soon. It was once considered by many FreeBSDers among the best laptops in the market, but Open Source depends on standards, and IBM's failure to follow standards is too glaring to ignore.
I think the _real_ fear people have is the idea that the clone will have the same memories as the original, pretty much like what happens in "6th Day". This, coupled with the notion that a clone will have the same age as the original.
For this reason I believe that while opposing fanatics will always exist, most people will end up thinking there is no big deal about it, because their real fear had nothing to do with cloning in first place.
Actually, I think you can. They have visiting days or something like that, and I think there are periods where one can actually catch a demonstration ride.
:-)
Of course, there isn't much of a point in catching a train that only stop at one station.
No, the japanese bullet trains do not run on maglev at all.
The japanese *do* have a maglev project, though, and they have a few miles of it they use for various tests.
Japan is already too advanced in their own maglev project. They already have a good section of it, on which they have been conducting experiments, and I find it difficult anything China starts doing _now_ will get finished before the Tokyo-Osaka line.
If you can't distinguish the real thing from the fake, then make it a requirement to have all the software/data needed to produce the fake from the scratch. Just like it's already a requirement to be able to prove all actors in a porn movie are above 18.
This argument of feasibility of prosecution is wrong.
First, you are all talking about "virtual indistinguishable from real." Well, fine. Go after *THAT*. But the issue here is virtual *clearly* distinguishable from real. You are proposing to outlaw *THAT* just cover the former case?
Second, if the former case becomes real, just make it a law keeping proof of the "making of". Ie, if you sell something indistinguishable from the real thing, you have to be able to provide the program and the data you used producing it. This is *NOT* undue burden. This kind of thing exists already. If you make a porn movie, you have to keep proof that all actors were of legal age. Financial institutions have to keep all sorts of data proving they did things legally.
Don't make me laugh! What's the capacity of the power supply unit of your super-powerful computer? 250W? 300W? That's the *maximum*, but never mind that, let's assume you are actually using that much power. That's 3 lamps. 5 of the very weak 60W lamps.
How much does your microwave uses? 500W? 750? What about your toaster? 1000W? 1500W? Electrical heater: 2000W? 2500W? Refrigerator, freezer, electrical boiler, water heater, hair drier, TV... your computer doesn't even make a dent on what you are paying (and consuming).
There are two reasons for the California problem:
1) The power companies put all new power station development on hold until the deregulation was through, to see what kind of playing field they would have. The deregulation was long, and the power consumption skyrocketed all through it.
2) The power companies were incompetent, resulting in very bad deals and power consumption predictions.
They can't spot a troll when they see one.
Aha! Just found the ECN reference! It's not a standard, it's a work-in-progress. So your point is? :-)
:-)
Let's talk about New Reno instead.
And if any of that were true, you wouldn't be posting as AC.
Face it, "Home and Garden" is probably more interesting.
-- Linus Torvalds
My point exactly. :-)
It's very appropriate for the Monolith to appear on Seattle. After all, in the movies it always appeared where no intelligent life was to be found.
A multithreaded IP stack doesn't make it faster. As a matter of fact, it's necessarily slower than it would be possible with a non-multithreaded stack, all other things being equal.
What it DOES make for is for greater performance on SMP systems and with multiple NICs.
FreeBSD is reputed to have a faster IP stack, as far as UP systems go. I don't know whether that's true or not, but many ex-Linux FreeBSD users do claim so. The huge (and record) throughput on ftp.freesoftware.com (formely ftp.cdrom.com) is sometimes cited as proof.
As for Windows, I don't know about 2000, but NT does have a multithreaded IP stack, one of the reasons why it beat the hell out of Linux (and FreeBSD) on a famous benchmark.
Still, real world throughput is likely to depend much more heavily on simple things like the accept filters or the kqueue interface than on the IP stack speed.
And while all the above might be true or not, it's not really the reason why heavy weights chose FreeBSD. What makes FreeBSD special for many is it's capability to handle heavy loads gracefully.
SMP-safe? Sure FreeBSD's TCP is SMP-safe. You can run it on SMP without ever running into a single problem. Maybe you wanted to say something else?
I must confess I never even heard of ECN and SACK, which doesn't really mean much. We do care a lot about standards, though. As it should be obvious to anyone with the least historical knowledge, in the absence of actual contact with the current developer community.
Benchmarks. Yeah, we probably should optimize for benchmarks, like developing an ultrafast getpid() system call, so benchmarks which use that as a "null" system call show faster results. Instead, we spend time uselessly on optimizing for real world use. Sigh. We are so foolish! If we aimed at being good on paper instead of being good on practice, we could grab a much larger market share in exchange for a few really heavy sites that absolutely need us!
UFS is over 10 years old. Well, softupdates isn't, but that's beside the point. UFS still kick ass. There is a whole class of ex-Linux FreeBSD users whose main concern was the superiority of UFS over ext2.
As for Linux UFS, last I heard it was "use at your own risk", and not particularly fast at it.
Sure enough, Reiserfs, Tux2, JFS, XFS and ext3 will, eventually, all kick ass. Well, scratch JFS off that list, since it was based on a really slow version. Heck, Reiserfs is kicking ass now, as a matter of fact, despite some claims that it is infringing on some patents.
Yep. Not to mention two people called it "overrated", probably to offset the ones who thought it "funny", which it really is.
:-)
Some people have no sense of humor.
Yeah, keep trying. One day you might manage to convince yourself of that, and then there will be one person in the world believing it. :-)
How can "OpenBSD rules" possibly be off-topic? It's entirely on-topic for this story, and since this *is* an OpenBSD story, it can't even be called a flamebait (it insults no one else, and certainly not the OpenBSD users).
ext2fs is *NOT* experimental. It's not experimental on 4.2, nor was it experimental in 3.x, nor even on 2.x.
What happens is Linux have been adding features to ext2fs, which FreeBSD, obviously, always lag behind.
This is a _fair_ question. The recent releases of FreeBSD, OpenBSD and NetBSD (1.4.3) all got the front page. Why didn't 1.5?