Using a RAM disk is actually harmful to system performance, because the OS may not be able to cache disk sectors that are frequently needed.
The ramdisk and the OS's caches are both living in the same memory store; the cache won't be much faster, if any at all, and that only by the OS maybe having a less complicated way to get at the data. Thus, any improvement gained by duplicating ramdisk virtual sectors in a cache would be marginal. Ideally, the OS shouldn't cache any of it; the entire ramdisk is the freaking cache. The ramdisk idea is smart.
Maybe you thought this was going to be a funny post. It is not. My claim: it is *wonderful* fun to play with early unices on their original machines. If this news story interests you, you should get yourself a PDP-11 or a VAX.
You can still find PDP-11s and VAXen if you look hard enough -- sometimes with little or no impact on your wallet. After one year of searching, I possess five 11s and three VAXen, and I've even had to pass on some acquisition opportunities. Plus, while some 11s are serious big iron, some are almost as small as an average PC. More recent VAXen actually do come in average-PC form factors.
There are also several large and very competent Internet communities centered around these machines. They're not that hard to locate. Join one of these, and you've got nearly instant help with getting yourself set up and running. Need tapes? Need that paper tape controller board? No problem. The only catch, of course, is that you'll have to do the same one day for all the future vintage hardware fans that are just now being born (as in babies, children, offspring).
So go grab yourself a PDP-11/73 and a VT220 and throw 2.11BSD on it. You'll enjoy every minute of it.
Re:Your own reference seems to contradict you
on
Black Holes Disputed
·
· Score: 2, Funny
scroll down to the bottom of the page, to see what happens when the angle of attack becomes too big. Yes, the upper and the lower flow no longer meet.
Yeah, but at that point, the airfoil is no longer generating lift, and the plane stalls. That seems to reaffirm the aerodynamics engineer's statements.
Also, think for a moment that you (YANAAE) are disputing the word of an aerodynamics engineer who works with this stuff every day. That's like disputing Alan Cox's idea of how the Linux kernel works.
The presumption could be that releasing source code allows the user to take responsibility for the correct operation of the software.
Someone replied:
That's a bit like saying a car company shouldn't be held responsible for putting faulty brakes on a car, since after all, the car owner could have replaced the brakes with something that worked.
Nope, sorry. That would only be the case if the car company released the complete designs for the car with a free-as-in-freedom-and-beer license, such that anyone could build an identical car or make their own modifications to the design. In that case, the car company indeed should not be held responsible for faulty brakes.
Come ON. Microsoft will not start artificially limiting what hardware it's product will run on. Why would they? That would be like throwing away customers!
Start? They've been doing that for ages. Levels of slowness and bloat in successive releases of Microsoft products are calculated and intentional. Look here:
Slowness and bloat make people want better computers.
People wanting better computers makes people buy more new computers.
People buying more new computers means more Windows/Office/etc. sales.
So, in some sick and twisted way, the more slow and bloated a product is, the more money it makes. The only upper limit is the bleeding edge of technology; there has to be some hope that new machines will be adequate to run the slow and bloated software.
And most MIS grads laugh at the CS people who shit their pants when giving public presentations, negotiating, or simply communicating with peers.
'CS people' generally do not exist to give public presentations, to negotiate, or to communicate with peers (under your definition of peers). Those are the ways of subspecies. 'CS people', among other activites, build the tools that make possible the meaningless labor of the 'MIS grad'.
Down the turnpike in Norman (University of Oklahoma, for the uninitiated), it works like this, unofficially:
If you're a sofware person, you do Computer Science (CS). CS is a department in the College of Engineering.
If you're a hardware person, you do Electrical and Computer Engineering (ECE). ECE is a department in the College of Engineering.
If you're not cut out for either CS or ECE, you do Management Information Systems (MIS). MIS is a department in the College of Business.
As an unrelated but true anecdote: One of the more well-known CS professors at OU was working at his office on a Saturday, during which time the football team was playing at an away game. Upon leaving his office, the professor was accosted by a local television reporter. Camera thrust in his face, the professor was asked, "So, what do you think about the game?" He replied, "Well, I knew something was up because all the parking lots were empty."
Assuming this is the implementation, in order to crack.NAP, you'd need a mechanism of sending your private key along with any.NAP file you send to another user.
Sure, you could do it that way, but why? There are other, easier ways. Remember that at some point before reaching your brain, the sound data is decrypted. In fact, it most likely is decrypted before being sent to the system's audio device. You simply need to capture the data after it has been decrypted by Napster. Some examples:
Copy directly out of Napster's buffer. This might be hard.
Write an audio driver that accepts audio data like any audio device but writes the data to a file.
Get a sound card with digital audio in/out, and either loopback it or use DAT (or a number of other possiblities) for temporary storage.
Loopback the analog in/out or use a temporary storage medium. This incurs loss of quality.
Stick a friggin' tape recorder in the same room as your computer. This incurs loss of quality.
You see, the only way to have truly secure music files is to have the decryption done in whatever part of your brain implements perception. Let's not think about that.
DirecTV, in all of its digital glory, only offers 2 HDTV channels. There's HBO HDTV, which requires HBO on your account, and HDNet, which comes with the base package (though much of it is pay-per-view). You also have to have a HDTV-capable receiver and an oval (multi-sat) dish.
Hey man, don't take it as a flame; I was merely attempting to give our Slashdot readers a wider education. I appreciate your comment very much.
The 45 and 70 were introduced in 1972 and 1975. You're right, though; the wider addresses were something of a kludge. Even in the machines with separate code and data address spaces, the most virtual memory a program could address was 128KB. Can I hear an "overlays"? Ugh!:-)
The PDP-10 and its children were indeed 36-bitters. People often wonder why the bitnesses DEC's pre-PDP-11 machines were always multiples of 6. It's fun to tell them "back in the day, a byte was not 8 bits, and octal made sense" and then watch enlightenment slowly spread over their face.
So certainly since at least 1984 or so Microsoft has basically had a monopoly position in OSes
Only on PC OSes. In 1984, PCs were not anywhere as inexpensive, featureful, and ubiquitous as they are today. This was especially true in business; you would be much more likely to find a VT220 on a worker's desk (if anything with a CRT at all) than an IBM PC. Unix, VMS, and others were still the leaders of the pack.
The transition of Digital machines was not so clear-cut. Yes, the PDP-11, which was made in various models from 1970 to 1990, was a very popular machine and was generally considered to be 16-bit. The first models had a true 16-bit address space, but later models improved upon that. The 11/45 introduced 18-bit addressing and separate address spaces for data and code. The 11/70 introduced 22-bit addressing.
Also, Digital was already making 36-bit machines, starting with the PDP-6 in 1964. The 36-bit PDP-10, which cam in several flavors, was quite popular and spawned quite a culture of its own.
Lastly, how can you not mention the 32-bit VAX? From 1976 to 1999 (!), this was Digital's 32-bit machine, and it was also very, very successful. By the time the Alpha hit the scene, the VAX had certainly taken over the supermicro/mini/supermini position formerly held by the PDP-11.
I like to bring the panel of core memory out at geek parties and show it to the younger crowd and see the reaction
I like to show them my workingPDP-11/20, complete with two 4Kword MM11-E core memories. Mine looks like the one in the picture there minus the disk cabinet on the left, the red panel at the top of the rack, and the ASR-33s. The machine was given to me free of charge, though I had to drive 2400 miles to get it.
Too bad there are no DECtape drives still in existence
Mine still works, and there are a few others out there that still have working ones. I've seen two units on eBay during the last year. There are people out there who are keeping this old technology alive.
compare Windows 2000 to another complete operating system, NOT a bleeding edge kernel
I think, though, that the stable Linux kernel should not be considered bleeding edge. It should be considered conservative and trustworthy. There are (should be?) unstable tracks/trees in which the developers can toy with bleeding-edge stuff, and those tracks/trees should be the only place where such experimentation is done. If the bleeding edge is not separated from the trustworthy, then we have no right to bitch when the industry shuns Linux-based solutions.
I, for one, would love to see Linux and other free Unices offer real competiton against the status quo, but it won't happen until more intelligent software engineering is in place.
As previous replies have explained, estimating the cost of maintenance of a software package is a much more complex issue than what what you are imagining. Here are my own points that explain how this can be:
Lines of code (LOC), when you mean the number of physical lines that are not blank or comments, is not a good measure of code size. What you really should measure is the number of logical operations that code does. At least one formal software engineering method calls this 'logical LOC' (LLOC).
Even when measuring with LLOC, any kind of LLOC/hour estimate is going to depend on all sorts of stuff:
Complexity of the product. Is it a RTOS, or is it a database front-end?
The programming language used. Which takes more thought per LLOC: VB, C, or 68K assembly?
The Software Engineers. How fast does Jim write code? How many defects does Jim's code usually contain? What is the cost of finding and fixing those defects?
Corporate culture. How much time will Jim spend writing code? How much time will he spend in meetings, code reviews, design reviews, and other distractions?
Getting good, consistent, trustworthy answers in an environment like this is hard, and it takes a good bit of analysis (with an emphasis on 'anal') and statistics (mmmm... multiple regression...). In a highly successful software engineering firm, this stuff is what (skilled) managers are for. If you are going to find yourself in that position, you really should read some of the more famous texts on software engineering and its formal methods.
The bottom line is this: when software projects require a team of developers, you've got to view it from the point-of-view of an engineer instead of that of an artisan.
Slashdot Mirror
Using a RAM disk is actually harmful to system performance, because the OS may not be able to cache disk sectors that are frequently needed.
The ramdisk and the OS's caches are both living in the same memory store; the cache won't be much faster, if any at all, and that only by the OS maybe having a less complicated way to get at the data. Thus, any improvement gained by duplicating ramdisk virtual sectors in a cache would be marginal. Ideally, the OS shouldn't cache any of it; the entire ramdisk is the freaking cache. The ramdisk idea is smart.
...uh, maybe, um, *remove* the RF tags after you've purchased the items?
Is that not possible with these tags, or is this whole discussion one big retardathon?
You [...] get electricity for free.
Well, most don't use *that* much juice, and I live in a part of the country where energy is not that expensive.
Maybe you thought this was going to be a funny post. It is not. My claim: it is *wonderful* fun to play with early unices on their original machines. If this news story interests you, you should get yourself a PDP-11 or a VAX.
You can still find PDP-11s and VAXen if you look hard enough -- sometimes with little or no impact on your wallet. After one year of searching, I possess five 11s and three VAXen, and I've even had to pass on some acquisition opportunities. Plus, while some 11s are serious big iron, some are almost as small as an average PC. More recent VAXen actually do come in average-PC form factors.
There are also several large and very competent Internet communities centered around these machines. They're not that hard to locate. Join one of these, and you've got nearly instant help with getting yourself set up and running. Need tapes? Need that paper tape controller board? No problem. The only catch, of course, is that you'll have to do the same one day for all the future vintage hardware fans that are just now being born (as in babies, children, offspring).
So go grab yourself a PDP-11/73 and a VT220 and throw 2.11BSD on it. You'll enjoy every minute of it.
Also, think for a moment that you (YANAAE) are disputing the word of an aerodynamics engineer who works with this stuff every day. That's like disputing Alan Cox's idea of how the Linux kernel works.
Yeah, well I'd rather have one of these, which is what I think of when I hear "minicomputer". Nyah!
Start? They've been doing that for ages. Levels of slowness and bloat in successive releases of Microsoft products are calculated and intentional. Look here:
- Slowness and bloat make people want better computers.
- People wanting better computers makes people buy more new computers.
- People buying more new computers means more Windows/Office/etc. sales.
So, in some sick and twisted way, the more slow and bloated a product is, the more money it makes. The only upper limit is the bleeding edge of technology; there has to be some hope that new machines will be adequate to run the slow and bloated software.And most MIS grads laugh at the CS people who shit their pants when giving public presentations, negotiating, or simply communicating with peers.
'CS people' generally do not exist to give public presentations, to negotiate, or to communicate with peers (under your definition of peers). Those are the ways of subspecies. 'CS people', among other activites, build the tools that make possible the meaningless labor of the 'MIS grad'.
- If you're a sofware person, you do Computer Science (CS). CS is a department in the College of Engineering.
- If you're a hardware person, you do Electrical and Computer Engineering (ECE). ECE is a department in the College of Engineering.
- If you're not cut out for either CS or ECE, you do Management Information Systems (MIS). MIS is a department in the College of Business.
As an unrelated but true anecdote: One of the more well-known CS professors at OU was working at his office on a Saturday, during which time the football team was playing at an away game. Upon leaving his office, the professor was accosted by a local television reporter. Camera thrust in his face, the professor was asked, "So, what do you think about the game?" He replied, "Well, I knew something was up because all the parking lots were empty."- Copy directly out of Napster's buffer. This might be hard.
- Write an audio driver that accepts audio data like any audio device but writes the data to a file.
- Get a sound card with digital audio in/out, and either loopback it or use DAT (or a number of other possiblities) for temporary storage.
- Loopback the analog in/out or use a temporary storage medium. This incurs loss of quality.
- Stick a friggin' tape recorder in the same room as your computer. This incurs loss of quality.
You see, the only way to have truly secure music files is to have the decryption done in whatever part of your brain implements perception. Let's not think about that.I think it's time to give my friends and family a forced feeding of some classic staples of anime, now that the Robotech Macross Saga DVDs are out.
Since they don't 'get it', they'll probably end up wishing it was a forced feeding of, well, 'regular' staples.
DirecTV, in all of its digital glory, only offers 2 HDTV channels. There's HBO HDTV, which requires HBO on your account, and HDNet, which comes with the base package (though much of it is pay-per-view). You also have to have a HDTV-capable receiver and an oval (multi-sat) dish.
In other words, don't get DirecTV.
Yeah, that will work.
Oooh, mod parent up! There's a programmer that has no strange religious distaste for the goto statement, one who realizes that it has its uses!
/* ... */
/* ... */
/* ... */
/* error handler */
I'd like to add one: error processing.
void func(void)
{
if (func1())
goto err;
if (func2())
goto err;
if (func3())
goto err;
return;
err:
}
And then your house catches on fire, and your data is gone. Go with hot-swappable, and keep a weekly backup offsite.
Hey man, don't take it as a flame; I was merely attempting to give our Slashdot readers a wider education. I appreciate your comment very much.
:-)
The 45 and 70 were introduced in 1972 and 1975. You're right, though; the wider addresses were something of a kludge. Even in the machines with separate code and data address spaces, the most virtual memory a program could address was 128KB. Can I hear an "overlays"? Ugh!
The PDP-10 and its children were indeed 36-bitters. People often wonder why the bitnesses DEC's pre-PDP-11 machines were always multiples of 6. It's fun to tell them "back in the day, a byte was not 8 bits, and octal made sense" and then watch enlightenment slowly spread over their face.
So certainly since at least 1984 or so Microsoft has basically had a monopoly position in OSes
Only on PC OSes. In 1984, PCs were not anywhere as inexpensive, featureful, and ubiquitous as they are today. This was especially true in business; you would be much more likely to find a VT220 on a worker's desk (if anything with a CRT at all) than an IBM PC. Unix, VMS, and others were still the leaders of the pack.
The transition of Digital machines was not so clear-cut. Yes, the PDP-11, which was made in various models from 1970 to 1990, was a very popular machine and was generally considered to be 16-bit. The first models had a true 16-bit address space, but later models improved upon that. The 11/45 introduced 18-bit addressing and separate address spaces for data and code. The 11/70 introduced 22-bit addressing.
Also, Digital was already making 36-bit machines, starting with the PDP-6 in 1964. The 36-bit PDP-10, which cam in several flavors, was quite popular and spawned quite a culture of its own.
Lastly, how can you not mention the 32-bit VAX? From 1976 to 1999 (!), this was Digital's 32-bit machine, and it was also very, very successful. By the time the Alpha hit the scene, the VAX had certainly taken over the supermicro/mini/supermini position formerly held by the PDP-11.
I like to bring the panel of core memory out at geek parties and show it to the younger crowd and see the reaction
I like to show them my working PDP-11/20, complete with two 4Kword MM11-E core memories. Mine looks like the one in the picture there minus the disk cabinet on the left, the red panel at the top of the rack, and the ASR-33s. The machine was given to me free of charge, though I had to drive 2400 miles to get it.
Too bad there are no DECtape drives still in existence
Mine still works, and there are a few others out there that still have working ones. I've seen two units on eBay during the last year. There are people out there who are keeping this old technology alive.
...that is, until someone cracks into you and stops your heart. Then it sucks tremendously.
compare Windows 2000 to another complete operating system, NOT a bleeding edge kernel
I think, though, that the stable Linux kernel should not be considered bleeding edge. It should be considered conservative and trustworthy. There are (should be?) unstable tracks/trees in which the developers can toy with bleeding-edge stuff, and those tracks/trees should be the only place where such experimentation is done. If the bleeding edge is not separated from the trustworthy, then we have no right to bitch when the industry shuns Linux-based solutions.
I, for one, would love to see Linux and other free Unices offer real competiton against the status quo, but it won't happen until more intelligent software engineering is in place.
- Lines of code (LOC), when you mean the number of physical lines that are not blank or comments, is not a good measure of code size. What you really should measure is the number of logical operations that code does. At least one formal software engineering method calls this 'logical LOC' (LLOC).
- Even when measuring with LLOC, any kind of LLOC/hour estimate is going to depend on all sorts of stuff:
- Complexity of the product. Is it a RTOS, or is it a database front-end?
- The programming language used. Which takes more thought per LLOC: VB, C, or 68K assembly?
- The Software Engineers. How fast does Jim write code? How many defects does Jim's code usually contain? What is the cost of finding and fixing those defects?
- Corporate culture. How much time will Jim spend writing code? How much time will he spend in meetings, code reviews, design reviews, and other distractions?
Getting good, consistent, trustworthy answers in an environment like this is hard, and it takes a good bit of analysis (with an emphasis on 'anal') and statistics (mmmm... multiple regression...). In a highly successful software engineering firm, this stuff is what (skilled) managers are for. If you are going to find yourself in that position, you really should read some of the more famous texts on software engineering and its formal methods.The bottom line is this: when software projects require a team of developers, you've got to view it from the point-of-view of an engineer instead of that of an artisan.