If the GPL chokes them, they can go with one of the BSD's.
Without knowing more, the initial reaction of any genineer should be that writing an operating system from scratch for the sake of supporting internet access devices is a ridiculous undertaking.
The internet access device is an application. You rarely need to write an OS to develop a new application!
Developing just the TCP/IP networking component of an OS is a major undertaking; one just has to look at the years of tweaking to cover up exploits in just about every implementation. Presumably, these guys are smart enough to at least use some off-the-shelf TCP/IP. (But then are they really developing the OS from scratch? Not wholly).
>While I'm still fairly new to the whole Linux/Unix world it seems to me that SCO >spent the last few years studying the finer points of FUD from MS.
No, it looks more like they spent the last few years sleeping, and are now reinventing the FUD thinking that they are saying something original.
Anyway, they are obviously going down when they have to drag out crap like this. FUD is a two way street; it alienates people who know better as much as it bamboozles peole who don't. It is like a bluff in a cards game; the last resort of the loser.
SCO is going down the tubes, and everyone knows it, and has known it for a long time. It's SCO shareholders that should be experiencing fear, uncertainty and doubt.
Whereas many computer geeks might not believe in all that fairy tale religion twaddle, a lot of people do, particularly in small town (or should I say, small mind) America. Having the wrong symbol represent your product can hurt you in the marketplace. You want to avoid swastikas, pentagrams, devils, etc---basically any sort of powerful symbol with deeply rooted negative cultural connotations.
Then again, it doesn't seem to hurt Dirt Devil vaccum cleaners.;)
The Unisys web page contains instances of question marks where apostrophes should be. This indicates that some Microsoft program was used to construct the HTML. Not only are they assholes, but they look like morons too.
The AOL client simply sends a longer message that is recognized specially. A buffer overflow is not needed in order to do this, and that's probably not how it's done. I doubt that someone would purposely, not to mention needlessly, introduce a horrible defect into their software. So the whole bit about AOL compromising security is just Microsoft FUD against AOL. I don't think that the ``security'' company in question have any clue how big the actual receive buffer size is that is declared in the software but are just hypothesizing. AOL is using Microsoft tactics against Microsoft, and it's pissing Microsoft off.:)
I was especially rolling on the floor laughing when they said that the actual stack was only done in 256 words, and the rest was for miscellaneous code! Masterful comedy.
I remember programming contests back in the early 80's having to do with what you could pack into 256 bytes of code (for your eight bit micro like the Apple II or what have you). People did some amazing things. But nothing like TCP/IP.
Consider this: on the Apple II computer, each peripheral had 256 bytes of memory mapped space, in which it could implement a driver. There existed serial drivers that barely fit into that limit, and these had only basic functions for transmitting and receiving characters in a blocking fashion plus a few other functions.
I had a modem whose hardware was very simple, but which did not manage to cram everything into the 256 limit. There was also a 2K space that was shared by all the devices (one at a time) so most of the modem's driver was crammed into there.
This was very tight coding. The 256 byte basic area even had overlapping instructions to save space. That is, the data part of one instruction serving as the opcode of another instruction. (Some biological viruses do something like this in their genetic code: two different proteins generated by overlapping areas in the code).
Anyway, the whole thing is a joke, probably inspired by some recent ``world's smallest web server'' slashdot stories.
Hey, maybe Linus is just trying to not appear as a snob. I'm not saying that he would say that he likes Hollywood entertainment better just because he doesn't want to offend, but it could be that the interviewer is reading too much into whatever he might have said. I'm thinking that Linus could have said that he likes some Hollywood movies, and the interviewer spun that into ``prefers Hollywood movies to highbrow European art films''. In reality, the man probably enjoys a bit of both and probably takes each film on its own merit rather than judging it by where it came from.
I mean what's he going to say? That Hollywood movies are shallow, mindless trash compared to European art movies? Coming from a recent comer from the Old World it would be seen as blatant euro-snobbery, even though everyone knows that it's true.:)
There was some good information about this in the critique that Andy Bakun wrote in response to The Open Source Acid Test article. He measured 2.2.0pl8 at 1,598,764 lines. A far cry from the half million that this article claims.
First of all, Linus didn't write all of the half a million lines that they say are in the kernel (and it's surely much more than a million by now at the rate drivers are added? I haven't done a count in a while) Secondly, comparing only the number of lines in the Linux kernel to all of Windows is stupid. To make a more meaningful comparison, you have to count glibc2 and all the other libraries, as well the X server, and probably a few of the important daemons! It's not like Windows NT is millions of lines lines of just kernel code!!!
That Ted Lewis cheesehead made the same mistake in that ``Open Source Acid Test'' embarassement, when he claimed that Linux's million lines of code do not approach the more than ten million in a real UNIX, and that Linux will have to get that big before it can compete.
First of all, Microsoft Word is not a suitable software package for writing professional documentation. I don't know what your superiors mean by ``document control'', but it sure is difficult to do version control on binary files. Resist Microsoft Word.
I do Windows NT development, yet I run LaTeX (on NT) for documentation. Pepole want MS Word around here too, but they can stuff it. If I'm going to document, it will have to be with the right tools that save time and energy. LaTeX also allows me to easily carve up the document into multiple files which are checked into the version control system separately. Since our stupid version control system has strict locking (should be using CVS, doh!) this helps when two or more people need to modify the document. I can also use keyword expansion to label checked out copies of the document automatically so it's clear where they come from in the revision control system, and what version they are.
My second point is this: your superiors clearly don't know how to manage the risks of software development, and are trying to fall back on a naive ``waterfall model''. In this model, a carefully managed paper trail is supposed to lead up to the working product. One begins with the Exctracted Requirements, then moves on to the Requirements Specification, followed by the High Level Design, and the Detailed Design. CASE tools may be involved. Only at the end of the paper trail does the coding begin.
This model is unrealistic, difficult to follow to the letter, and increases your time to delivery by wasting everyone's time with paperwork. It's also unrealistic to assume that the requirements will never change, or that the design won't have to be modified after the coding has begun. It's a huge waste of time to polish documents that may turn out later to be wrong or obsolete.
The activities of designing, docuemnting and coding should be done in parallel with development. Often, it's acceptable to produce a design document after the coding is already done, as a way of gathering recording the intellectual work done by the developers. The design document can use elements from e-mails among developers, and their scrapbooks and whatnot. (It's not like nothing is recorded as the software is developed, it's just that it's not in a polished document!)
What you should do is settle on the requirements specification first, and then run with it. If your project is split up into teams whose software components have to communicate using tight interfaces, then design and document those interfaces, but don't worry about the internals too much. Write only those documents that are essential for everyone to be unblocked so they can go on with the business of writing the software. You need to know what the requirements are, and you need to know the interfaces to software components that other teams are working on, so it's good to have these captured early on. Worry about the design documentation later; wait until at least you are past the prototype stage and are into version 1.0.
If the Windows hegemony can be attributed solely to the ease of use of Windows, then how do you explain the DOS monopoly that preceded it? For example, why was the functionally equilvalent DR-DOS crushed? Were its commands any more difficult to use than those of MS-DOS?
Yer clueless, and you are recycling the same old FUD about how UNIX systems have no graphical interface. Your $0.02 is worth about $0.0002 where I'm sitting.
The 80 degrees refers to the incline of the first drop, not to banking. If you are freely accelerating down an 80 degree incline, the force you are experiencing is somewhere between 0g and 1g (assuming we ignore the effects of air resistance, which would ultimately lead you to attain terminal velocity---the track is not long enough for that).
So the table would be:
0 degrees (level): 1.00 g 45 degrees: 0.71 g (~ sqrt(2)/2) 60 degrees: 0.50 g 80 degrees: 0.17 g 90 degrees: 0.00 g
Basically, the g's correspond to the cosine of the angle. Switch your calculator to degrees, punch in the degree of inclination and hit the COS button. That's the amount of force that you experience.
The 80 degree drop will feel nearly weightless. Also, the force you will experience will be normal to the seat. As you enter the drop, the change in the direction and magnitude of the force you are experiencing will feel like you are being lifted off the track.
Of course, you will experience some serious g's greater than 1 at the bottom of the drop. That's a matter of gravity, the speed at which you are going and the curvature of the track.
The sheer length and steep angle of that drop is going to make this one scary rollercoaster.
What do you call CD's then? The industry has been selling digital music already for years, just not online.
When you buy a CD, you are getting a bunch of files that you can copy, and the purveyors know that you can copy them.
I suspect that the music industry has anticipated that hardware would eventually get to the point where it enables people to casually trade music files. They just didn't count on it happening so soon thanks to very effective lossy audio compression.
There is no fundamental difference between shipping data on polycarbonate or doing it over a network. Either way, the possibility exists that someone will buy one copy and then duplicate it countless times.
So it's not real news that the industry is getting in on the action, any more than it's newsworthy that some software company is delivering software to a client over a network.
Everyone wants to get into online sales, and it makes particular sense for software of any kind, because of the reduced manufacturing and distribution costs. The losers in this will probably be the music retail outlets, who will become increasingly obsolete.
Mount the filesystems of the systems being backed up and then simply archive to tape on the server side. The clients don't need any special software to connect to a ``backup daemon'' on the server. The problem then boils down to supporting the various filesystems.
Borland is obsolete. Their C compiler was used initially because that's what Minix was compiled with. But that lasted only until Linux was good enough to support a real compiler.
First of all, the ``twice the RAM size'' rule is a moronic leftover from operating systems which used swap in a backing storage manner. On these systems, the virtual memory size was equal to the swap size, with RAM serving as a sort of high-speed cache over that without contributing to the amount of swap. Meaning that there *had* to be at least as much swap as RAM for architectural reasons. In Linux, the total space available is the *sum* of the swap size and RAM size, so that rule of thumb, for what it may be worth, needs to be modified to: have as much swap as you have RAM.
Of course, the problem with rules of thumb is that not all thumbs are the same.
Ideally, you don't want any swap space at all. In practice you have to look at how much virtual space your applications need, and then decide how much of that space you can afford to represent with real RAM.
If you need a peak value of 256 megabytes of memory to do what you want, and you have 64 megabytes of RAM, then you will obviously need 192 megabytes of swap space. If what you are doing won't run well unless all 256 megabytes are real RAM, then you will have to get 256 megabytes of ral RAM, in which case you then won't need any swap at all (but you can always have swap for the hell of it for for emergencies).
Whether or not it's efficient to meet needs with a large amount of swap depends on the locality of memory references within the applications you are going to be running. Some applications simply won't run well if you don't have actual RAM, others might. Applications that have a small access pattern, but large memory usage (because, for instance, they have nasty memory leaks:) will benefit from a large swap space (the leaking ones will be able to run longer, if not better:). Applications that periodically access large areas of memory will need actual RAM. For example, image processing or scientific simulations with huge arrays.
So there is no one-size-fits-all rule of thumb; you have to consider the nature of the application. First estimate the memory usage, trying to err on the side of too high rather than too low. Then based on the application type, determine how much swap is sufferable. Perhaps as little as one fourth of the total requirement needs to be physical RAM. Or maybe the whole thing has to be RAM.
Also, simply set a low cutoff limit based on the RAM market. For example, these days, you might want to assume that there will be 128 megs of real RAM no matter what and proceed from there.
If something falls under one of the GNU licenses, I tend to call it ``GNU software'', even if it's not from the FSF. That is clear enough, at least for that class of software.
You should compile your kernel with support for a serial console. Then add a getty line to your/etc/inittab to run a getty on the tty line. You should also modify your lilo.conf to enable the console on a serial line.
I was playing with this a few days ago, but my old terminal blew up on me!
Also, if you want to reset the machine by sending break, you have to do a little kernel modification in/usr/src/linux/drivers/char/serial.c. The current code will generate a SIGINT signal to the foreground process group if a break is sent. (If the BRKINT termios option is enabled, and IGNBRK is not enabled). There is also support for the break signal to act as the SAK (secure attention key). It shouldn't be too hard to force a reboot if a break is received. I don't think that you can reboot the machine from within an interrupt context, but you could wake up a ``watchdog'' process which will do the reboot. Add an ioctl() which causes the calling process to block indefinitely. When a break is received, wake up the process. Then write a userland process that opens the tty, calls the ioctl and then reboots the machine if the ioctl returns with a successful error code. This is largely trivial to write, since the code for handling break is already there.
The ioctl could be wrapped up in a tiny tool which is then used in a shell script that runs/sbin/shutdown:
if shutdown_watcher/dev/ttyS0 ; then /sbin/shutdown -r now fi
Of course, if the machine is too hosed to reboot, this obviously won't work. A hardware solution is required that turns the break signal into a hard reset.
Not to mention that it creates confusion in the mind of any manager who knows about the OSI seven layer model for creating a submarine sandwich.
``Open source'' is dead. The only thing ``open source'' had going for it was that it was supposedly going to be protected by a trademark. Now the term is is no longer going to deliver that and is going to be abused even more by vendors of proprietary technology, because it has become a hot buzzword. Going open source is ``in'', and now you can release your product with arbitrary restrictions and say that you are going open source, without fearing repercussions from trodding upon a trademark.
As of now, I'm going to avoid using the term open source except perhaps in reference to proprietary products whose source code is released with restrictive licenses. I'm going back to calling truly free software ``freeware''.
So Linux is controlled by a small group of hackers who continue putting out patches, forcing people who have customized kernels to keep re-testing. And this is a bad thing!
Lovely argument there, eh? It's not enough to have free OS code that you can customize, the hackers who wrote it must also step aside and stop working on it so that they don't break customized, unreleased versions of the software maintained by your shop!
Nobody forces you to use the latest kernel. Moreover, if you obey the major interfaces within the kernel, your code will remain compatible. If you upgrade to a new kernel, you have to re-test and possibly change your code. This is no different than if you were doing application level coding in any operating system. If you develop, say, a middleware service application for NT, you have to re-test everything if you decide to support the lastest service pack.
I recently upgraded the Mobitex radio modem driver from supporting only the 2.0.x kernels to 2.2.x. It was pretty easy despite the quantum leap in kernel revisions. Some of the network driver interfaces had changed---for the better, I might add. Adapting the code made some of it it simpler and cleaner. The only real sneaky thing was that the tty line discipline receive callback can now be run in a true interrupt context right from the underlying serial driver, rather than as a mere bottom half callback! So the reentrancy assumptions in the driver had to be re-evaluated, and stricter locking had to be put in (at which point I went straight to using the new SMP friendly spin locks). So most of the porting issues were caught at compile time, and the rest by prudent code re-reading and re-evaluating of old assumptions.
But we are talking about a serious jump between major release series, not from one version to the next within a series. Incrementally supporting successive kernel releases tends to be trivial. Being a responsible developer means that of course you redo all of your usual test cases before approving the software as working with a given kernel, and you document which kernels it was tested with with.
In the case of unreleased in-house changes, it's even easier because you don't owe it to any outside users to support a variety of kernels. You can simply pick a kernel and stick with that for a while as a matter of internal policy.
If you are working on modifying some area of the kernel that is also being ``churned'' by the main developers, and you want them do to certain things your way, then you have to communicate and resolve the issues. Chances are that they won't listen to you if the issues are related to proprietary modifications that aren't being released back into the community. Well doh!
How anyone can twist availabily of source code into a FUD argument against Linux is beyond me. If you don't like the churning, don't stop for drinks at the Kernel of the Week club on the way home every Friday night. Have a prudent roadmap for upgrades.
This fruitcake disgusts me. I have no respect for people who parrot other people's FUD without understanding what they are talking about.
I see no evidence that this dude knows anything about operatng systems internals, and I doubt that he has ever written a line of kernel code. I also don't believe that he has any experience maintaining custom patches against a code base whose mainstream releases are controlled by someone else.
So when he writes that rapid kernel development is a problem for people who maintain modifications, it must be taken with a sizeable crystal of salt. Ditto when he says this or that about Linux SMP; he just heard it from someone, who in turn heard it from someone else, and so on...
It shows that NT needs a behemoth computer to run well, whereas it is targeted at the low-end market which does not use behemoth computers. NT needs the hardware to run well.
Believe me, NT does not run well, for instance, on my 450 Mhz PIII with 128 megs of RAM, all things considered.
Linux has a history of keeping abreast with reality. When nearly everyone has a four or eight CPU monster, then Linux will run like hell on them, and so will applications such as Apache, etc.
When everyone had a 386, Linux ran well on a 386. When everyone had a 486, Linux ran well on that (and still does!). Linux is made to fit a need, not to participate in olympic events.
I have an 8MB 486 at work on which I need Linux to run well. It does. In all likelihood, NT 4 won't even boot on such a machine. The machine has no keyboard or monitor, yet I can completely administer and upgrade it. NT would be useless on it since it requires a graphical display, mouse and keyboard for administration.
What you want is ssh. The cleartext authentication mechanisms of telnet and ftp are too insecure.
The users should develop the web site on their local hard drive and then simply synchronize files with some secure transfer like ``scp -R my_dir me@website.com:public_html''
That gives you the most flexibility. You can version control all your stuff locally, test it carefully, etc.
The web server is just a place where you showcase a snapshot of your work. It's not where the work should be taking place. That's just fundamentally dumb.
Slashdot Mirror
If the GPL chokes them, they can go with one of the BSD's.
Without knowing more, the initial reaction of any genineer should be that writing an operating system from scratch for the sake of supporting internet access devices is a ridiculous undertaking.
The internet access device is an application. You rarely need to write an OS to develop a new application!
Developing just the TCP/IP networking component of an OS is a major undertaking; one just has to look at the years of tweaking to cover up exploits in just about every implementation. Presumably, these guys are smart enough to at least use some off-the-shelf TCP/IP. (But then are they really developing the OS from scratch? Not wholly).
>While I'm still fairly new to the whole Linux/Unix world it seems to me that SCO
>spent the last few years studying the finer points of FUD from MS.
No, it looks more like they spent the last few years sleeping, and are now reinventing the FUD thinking that they are saying something original.
Anyway, they are obviously going down when they have to drag out crap like this. FUD is a two way street; it alienates people who know better as much as it bamboozles peole who don't. It is like a bluff in a cards game; the last resort of the loser.
SCO is going down the tubes, and everyone knows it, and has known it for a long time. It's SCO shareholders that should be experiencing fear, uncertainty and doubt.
Whereas many computer geeks might not believe in all that fairy tale religion twaddle, a lot of people do, particularly in small town (or should I say, small mind) America. Having the wrong symbol represent your product can hurt you in the marketplace. You want to avoid swastikas, pentagrams, devils, etc---basically any sort of powerful symbol with deeply rooted negative cultural connotations.
;)
Then again, it doesn't seem to hurt Dirt Devil vaccum cleaners.
The Unisys web page contains instances of question marks where apostrophes should be. This indicates that some Microsoft program was used to construct the HTML. Not only are they assholes, but they look like morons too.
who wrote those cool games for the Apple II like Dung Beetles?
The AOL client simply sends a longer message that is recognized specially. A buffer overflow is not needed in order to do this, and that's probably not how it's done. I doubt that someone would purposely, not to mention needlessly, introduce a horrible defect into their software. So the whole bit about AOL compromising security is just Microsoft FUD against AOL. I don't think that the ``security'' company in question have any clue how big the actual receive buffer size is that is declared in the software but are just hypothesizing. AOL is using Microsoft tactics against Microsoft, and it's pissing Microsoft off. :)
You positively cannot do TCP in 512 12 bit words.
Look, the page starts out with a joke.
I was especially rolling on the floor laughing when they said that the actual stack was only done in 256 words, and the rest was for miscellaneous code! Masterful comedy.
I remember programming contests back in the early 80's having to do with what you could pack into 256 bytes of code (for your eight bit micro like the Apple II or what have you). People did some amazing things. But nothing like TCP/IP.
Consider this: on the Apple II computer, each peripheral had 256 bytes of memory mapped space, in which it could implement a driver. There existed serial drivers that barely fit into that limit, and these had only basic functions for transmitting and receiving characters in a blocking fashion plus a few other functions.
I had a modem whose hardware was very simple, but which did not manage to cram everything into the 256 limit. There was also a 2K space that was shared by all the devices (one at a time) so most of the modem's driver was crammed into there.
This was very tight coding. The 256 byte basic area even had overlapping instructions to save space. That is, the data part of one instruction serving as the opcode of another instruction. (Some biological viruses do something like this in their genetic code: two different proteins generated by overlapping areas in the code).
Anyway, the whole thing is a joke, probably inspired by some recent ``world's smallest web server'' slashdot stories.
Hey, maybe Linus is just trying to not appear as a snob. I'm not saying that he would say that he likes Hollywood entertainment better just because he doesn't want to offend, but it could be that the interviewer is reading too much into whatever he might have said. I'm thinking that Linus could have said that he likes some Hollywood movies, and the interviewer spun that into ``prefers Hollywood movies to highbrow European art films''. In reality, the man probably enjoys a bit of both and probably takes each film on its own merit rather than judging it by where it came from.
:)
I mean what's he going to say? That Hollywood movies are shallow, mindless trash compared to European art movies? Coming from a recent comer from the Old World it would be seen as blatant euro-snobbery, even though everyone knows that it's true.
There was some good information about this in the critique that Andy Bakun wrote in response to The Open Source Acid Test article. He measured 2.2.0pl8 at 1,598,764 lines. A far cry from the half million that this article claims.
There was some good information about this in the critique that Andy Bakun wrote in response to The Open Source Acid Test article. He measured 2.2.0pl8 at 1,598,764 lines. A far cry from the half million that this article claims.
First of all, Linus didn't write all of the half a million lines that they say are in the kernel (and it's surely much more than a million by now at the rate drivers are added? I haven't done a count in a while) Secondly, comparing only the number of lines in the Linux kernel to all of Windows is stupid. To make a more meaningful comparison, you have to count glibc2 and all the other libraries, as well the X server, and probably a few of the important daemons! It's not like Windows NT is millions of lines lines of just kernel code!!!
That Ted Lewis cheesehead made the same mistake in that ``Open Source Acid Test'' embarassement, when he claimed that Linux's million lines of code do not approach the more than ten million in a real UNIX, and that Linux will have to get that big before it can compete.
First of all, Microsoft Word is not a suitable software package for writing professional documentation. I don't know what your superiors mean by ``document control'', but it sure is difficult to do version control on binary files. Resist Microsoft Word.
I do Windows NT development, yet I run LaTeX (on NT) for documentation. Pepole want MS Word around here too, but they can stuff it. If I'm going to document, it will have to be with the right tools that save time and energy. LaTeX also allows me to easily carve up the document into multiple files which are checked into the version control system separately. Since our stupid version control system has strict locking (should be using CVS, doh!) this helps when two or more people need to modify the document. I can also use keyword expansion to label checked out copies of the document automatically so it's clear where they come from in the revision control system, and what version they are.
My second point is this: your superiors clearly don't know how to manage the risks of software development, and are trying to fall back on a naive ``waterfall model''. In this model, a carefully managed paper trail is supposed to lead up to the working product. One begins with the Exctracted Requirements, then moves on to the Requirements Specification, followed by the High Level Design, and the Detailed Design. CASE tools may be involved. Only at the end of the paper trail does the coding begin.
This model is unrealistic, difficult to follow to the letter, and increases your time to delivery by wasting everyone's time with paperwork. It's also unrealistic to assume that the requirements will never change, or that the design won't have to be modified after the coding has begun. It's a huge waste of time to polish documents that may turn out later to be wrong or obsolete.
The activities of designing, docuemnting and coding should be done in parallel with development. Often, it's acceptable to produce a design document after the coding is already done, as a way of gathering recording the intellectual work done by the developers. The design document can use elements from e-mails among developers, and their scrapbooks and whatnot. (It's not like nothing is recorded as the software is developed, it's just that it's not in a polished document!)
What you should do is settle on the requirements specification first, and then run with it. If your project is split up into teams whose software components have to communicate using tight interfaces, then design and document those interfaces, but don't worry about the internals too much. Write only those documents that are essential for everyone to be unblocked so they can go on with the business of writing the software. You need to know what the requirements are, and you need to know the interfaces to software components that other teams are working on, so it's good to have these captured early on. Worry about the design documentation later; wait until at least you are past the prototype stage and are into version 1.0.
Hope this makes some sort of sense.
You people have to start being anonymous cowards and identify your sorry asses to the rest of the world. :)
If the Windows hegemony can be attributed solely to the ease of use of Windows, then how do you explain the DOS monopoly that preceded it?
For example, why was the functionally equilvalent DR-DOS crushed? Were its commands any more difficult to use than those of MS-DOS?
Yer clueless, and you are recycling the same old FUD about how UNIX systems have no graphical interface. Your $0.02 is worth about $0.0002 where I'm sitting.
The 80 degrees refers to the incline of the first drop, not to banking. If you are freely accelerating down an 80 degree incline, the force you are experiencing is somewhere between 0g and 1g (assuming we ignore the effects of air resistance, which would ultimately lead you to attain terminal velocity---the track is not long enough for that).
So the table would be:
0 degrees (level): 1.00 g
45 degrees: 0.71 g (~ sqrt(2)/2)
60 degrees: 0.50 g
80 degrees: 0.17 g
90 degrees: 0.00 g
Basically, the g's correspond to the cosine of the angle. Switch your calculator to degrees, punch in the degree of inclination and hit the COS button. That's the amount of force that you experience.
The 80 degree drop will feel nearly weightless.
Also, the force you will experience will be normal to the seat. As you enter the drop, the change in the direction and magnitude of the force you are experiencing will feel like you are being lifted off the track.
Of course, you will experience some serious g's greater than 1 at the bottom of the drop. That's a matter of gravity, the speed at which you are going and the curvature of the track.
The sheer length and steep angle of that drop is going to make this one scary rollercoaster.
What do you call CD's then? The industry has been selling digital music already for years, just
not online.
When you buy a CD, you are getting a bunch of files that you can copy, and the purveyors know that you can copy them.
I suspect that the music industry has anticipated that hardware would eventually get to the point where it enables people to casually trade music files. They just didn't count on it happening so soon thanks to very effective lossy audio compression.
There is no fundamental difference between shipping data on polycarbonate or doing it over a network. Either way, the possibility exists that someone will buy one copy and then duplicate it countless times.
So it's not real news that the industry is getting in on the action, any more than it's newsworthy that some software company is delivering software to a client over a network.
Everyone wants to get into online sales, and it makes particular sense for software of any kind, because of the reduced manufacturing and distribution costs. The losers in this will probably be the music retail outlets, who will become increasingly obsolete.
Mount the filesystems of the systems being backed up and then simply archive to tape on the server side. The clients don't need any special software to connect to a ``backup daemon'' on the server. The problem then boils down to supporting the various filesystems.
Borland is obsolete. Their C compiler was used initially because that's what Minix was compiled with. But that lasted only until Linux was good enough to support a real compiler.
First of all, the ``twice the RAM size'' rule is a moronic leftover from operating systems which used swap in a backing storage manner. On these systems, the virtual memory size was equal to the swap size, with RAM serving as a sort of high-speed cache over that without contributing to the amount of swap. Meaning that there *had* to be at least as much swap as RAM for architectural reasons. In Linux, the total space available is the *sum* of the swap size and RAM size, so that rule of thumb, for what it may be worth, needs to be modified to: have as much swap as you have RAM.
:) will benefit from a large swap space (the leaking ones will be able to run longer, if not better :). Applications that periodically access large areas of memory will need actual RAM. For example, image processing or scientific simulations with huge arrays.
Of course, the problem with rules of thumb is that not all thumbs are the same.
Ideally, you don't want any swap space at all. In practice you have to look at how much virtual space your applications need, and then decide how much of that space you can afford to represent with real RAM.
If you need a peak value of 256 megabytes of memory to do what you want, and you have 64 megabytes of RAM, then you will obviously need 192 megabytes of swap space. If what you are doing won't run well unless all 256 megabytes are real RAM, then you will have to get 256 megabytes of ral RAM, in which case you then won't need any swap at all (but you can always have swap for the hell of it for for emergencies).
Whether or not it's efficient to meet needs with a large amount of swap depends on the locality of memory references within the applications you are going to be running. Some applications simply won't run well if you don't have actual RAM, others might. Applications that have a small access pattern, but large memory usage (because, for instance, they have nasty memory leaks
So there is no one-size-fits-all rule of thumb; you have to consider the nature of the application. First estimate the memory usage, trying to err on the side of too high rather than too low. Then based on the application type, determine how much swap is sufferable. Perhaps as little as one fourth of the total requirement needs to be physical RAM. Or maybe the whole thing has to be RAM.
Also, simply set a low cutoff limit based on the RAM market. For example, these days, you might want to assume that there will be 128 megs of real RAM no matter what and proceed from there.
If something falls under one of the GNU licenses, I tend to call it ``GNU software'', even if it's not from the FSF. That is clear enough, at least for that class of software.
You should compile your kernel with support for a /etc/inittab to run a getty on the tty line. You should also modify your lilo.conf to enable the console on a serial line.
/usr/src/linux/drivers/char/serial.c. The current code will generate a SIGINT signal to the foreground process group if a break is sent. (If the BRKINT termios option is enabled, and IGNBRK is not enabled). There is also support for the break signal to act as the SAK (secure attention key). It shouldn't be too hard to force a reboot if a break is received. I don't think that you can reboot the machine from within an interrupt context, but you could wake up a ``watchdog'' process which will do the reboot. Add an ioctl() which causes the calling process to block indefinitely. When a break is received, wake up the process. Then write a userland process that opens the tty, calls the ioctl and then reboots the machine if the ioctl returns with a successful error code. This is largely trivial to write, since the code for handling break is already there.
/sbin/shutdown:
/dev/ttyS0 ; then
/sbin/shutdown -r now
serial console. Then add a getty line to your
I was playing with this a few days ago, but my
old terminal blew up on me!
Also, if you want to reset the machine by sending break, you have to do a little kernel modification in
The ioctl could be wrapped up in a tiny tool which is then used in a shell script that runs
if shutdown_watcher
fi
Of course, if the machine is too hosed to reboot, this obviously won't work. A hardware solution is required that turns the break signal into a hard reset.
Not to mention that it creates confusion in the mind of any manager who knows about the OSI seven layer model for creating a submarine sandwich.
``Open source'' is dead. The only thing ``open source'' had going for it was that it was supposedly going to be protected by a trademark. Now the term is is no longer going to deliver that and is going to be abused even more by vendors of proprietary technology, because it has become a hot buzzword. Going open source is ``in'', and now you can release your product with arbitrary restrictions and say that you are going open
source, without fearing repercussions from trodding upon a trademark.
As of now, I'm going to avoid using the term open source except perhaps in reference to proprietary products whose source code is released with restrictive licenses. I'm going back to calling truly free software ``freeware''.
So Linux is controlled by a small group of hackers who continue putting out patches, forcing people who have customized kernels to keep re-testing. And this is a bad thing!
...
Lovely argument there, eh? It's not enough to have free OS code that you can customize, the hackers who wrote it must also step aside and stop working on it so that they don't break customized, unreleased versions of the software maintained by your shop!
Nobody forces you to use the latest kernel. Moreover, if you obey the major interfaces within the kernel, your code will remain compatible. If you upgrade to a new kernel, you have to re-test and possibly change your code. This is no different than if you were doing application level coding in any operating system. If you develop, say, a middleware service application for NT, you have to re-test everything if you decide to support the lastest service pack.
I recently upgraded the Mobitex radio modem driver from supporting only the 2.0.x kernels to 2.2.x. It was pretty easy despite the quantum leap in kernel revisions. Some of the network driver interfaces had changed---for the better, I might add. Adapting the code made some of it it simpler and cleaner. The only real sneaky thing was that the tty line discipline receive callback can now be run in a true interrupt context right from the underlying serial driver, rather than as a mere bottom half callback! So the reentrancy assumptions in the driver had to be re-evaluated, and stricter locking had to be put in (at which point I went straight to using the new SMP friendly spin locks). So most of the porting issues were caught at compile time, and the rest by prudent code re-reading and re-evaluating of old assumptions.
But we are talking about a serious jump between major release series, not from one version to the next within a series. Incrementally supporting successive kernel releases tends to be trivial. Being a responsible developer means that of course you redo all of your usual test cases before approving the software as working with a given kernel, and you document which kernels it was tested with with.
In the case of unreleased in-house changes, it's even easier because you don't owe it to any outside users to support a variety of kernels. You can simply pick a kernel and stick with that for a while as a matter of internal policy.
If you are working on modifying some area of the kernel that is also being ``churned'' by the main developers, and you want them do to certain things your way, then you have to communicate and resolve the issues. Chances are that they won't listen to you if the issues are related to proprietary modifications that aren't being released back into the community. Well doh!
How anyone can twist availabily of source code into a FUD argument against Linux is beyond me. If you don't like the churning, don't stop for drinks at the Kernel of the Week club on the way home every Friday night. Have a prudent roadmap for upgrades.
This fruitcake disgusts me. I have no respect for people who parrot other people's FUD without understanding what they are talking about.
I see no evidence that this dude knows anything about operatng systems internals, and I doubt that he has ever written a line of kernel code. I also don't believe that he has any experience maintaining custom patches against a code base whose mainstream releases are controlled by someone else.
So when he writes that rapid kernel development is a problem for people who maintain modifications, it must be taken with a sizeable crystal of salt. Ditto when he says this or that about Linux SMP; he just heard it from someone, who in turn heard it from someone else, and so on
It shows that NT needs a behemoth computer to run well, whereas it is targeted at the low-end market
which does not use behemoth computers. NT needs the hardware to run well.
Believe me, NT does not run well, for instance, on my 450 Mhz PIII with 128 megs of RAM, all things considered.
Linux has a history of keeping abreast with reality. When nearly everyone has a four or eight CPU monster, then Linux will run like hell on them, and so will applications such as Apache, etc.
When everyone had a 386, Linux ran well on a 386. When everyone had a 486, Linux ran well on that (and still does!). Linux is made to fit a need,
not to participate in olympic events.
I have an 8MB 486 at work on which I need Linux to run well. It does. In all likelihood, NT 4 won't even boot on such a machine. The machine has no keyboard or monitor, yet I can completely administer and upgrade it. NT would be useless on it since it requires a graphical display, mouse and keyboard for administration.
What you want is ssh. The cleartext authentication
mechanisms of telnet and ftp are too insecure.
The users should develop the web site on their local hard drive and then simply synchronize files with some secure transfer like ``scp -R my_dir me@website.com:public_html''
That gives you the most flexibility. You can
version control all your stuff locally, test it
carefully, etc.
The web server is just a place where you showcase
a snapshot of your work. It's not where the work
should be taking place. That's just fundamentally
dumb.