I don't know exactly when the change went in. But if its there, you want it. If you need it and don't have it, you'll know because X will be super slow (MIT-SHM obviously relys on SHM working).
Man, trying to secure a httpd written in sh is gonna suck. Just for starters, try: http://jester.vip.net.pl:8081/../../../../../../ ../../../../etc/passwd
It also appears you can execute arbitrary commands by changing your reverse DNS to contain the command and '|', ';' and/or '&'.
There is a good reason not to write CGI scripts in shell, and an even better one not to write a whole httpd!
everything (and I mean EVERYTHING) is an object. Classes are objects that descend from Class. Defining a subclass of another class entails sending a message (think method call) to the superclass telling it to hand me a subclass that declares x as a class variable, and y as an instance variable, and has the following methods.
Blocks of code are objects. like { code; code; } in java. You want to spawn off a thread? [ code to run in seperate thread. ] createProcess.
that sends the "createProcess" message to the block of code object.
java and C++ look like C with objects strapped on (imagine that) compared to smalltalk.
Of course, I failed to mention that its a pain in the ass, and slow too. =)
huh? so java's "int" primative is now an object? not with any compiler/vm I've ever used. The fact that your code is compiled to bytecode and executed by a VM is just an implementation issue. There can be (and are! towerj and gcj spring to mind) direct to native java compilers.
once you know a few procedural languages, and a few OO languages, and the concepts underlying each, you really should be able to pick up a new (procedural/OO) language in a weekend. The APIs might take longer, but that's not really a language issue.
Now if you know a bunch of procedural and OO languages, and you try to pick up LISP, it might take a little while, but that's because its a different model. Once you know a few functional languages, picking up a new one shouldn't take all that long either.
It would be nice if what you said was true, but its not. pmud is for bronze and earlier powerbooks only. The new firewire powerbook's PMU is unsupported. I think the iBook's PMU is also unsupported, but I am not sure.
To help out the spindown problem, try mounting your partitions noatime. This prevents it from writing to disk every time it accesses any page (even though the page is in cache). This usually lets the system spin down the hard drive for enough time to be worthwhile.
My 500Mhz g3 powerbook gets about 7 hours with both batteries in. Which is excellent considering linux doesn't support the PMU, so the hard drive is always on, the backlight is always on FULL BRIGHTNESS and the sound/ethernet/modem is always on.
Of course, I can't use it on my lap, because like a PIII laptop, it gets pretty hot as you run it.
rc5 (i know, i know) puts it about even with a desktop PIII-650. Which is especially impressive considering that a mobile PIII is slower than a desktop PIII.
I don't know if the price difference is worth it for apple desktop hardware, but for laptops, apple is the only way to go.
99% of the BSDers who slam linux installed linux is 1997, and switched to BSD in 1999 when linux got too popular. Now they need some reason to justify their move, other than "I don't feel 31337 using linux anymore."
The other 1% had their dog run over by linus torvalds when they were younger.
I'd like to take a moment to thank Amazon.com for forcing the issue of patent reform. If they maintain their current rate of ridiculous patenting, the patent office will soon be forced out of their complacent attitudes towards patents on the unpatentable. Without Amazon exploring the frontiers of idiotic patents, this process might takes years longer, making the damage much worse in the long run.
Now back to your regularly scheduled "i've patented xyz" posts.
Its a short range 2.4Ghz frequency hopping networking protocol. Applications are pretty much: Everythign irda was supposed to do but sucked at + audio distribution (IE, your cell phone turns into a landline phone when you're near your computer) + tons of neat-o new stuff (your palmpilot can dial a number on your cell phone).
There is a reasonably good article about it in the latest Dr. Dobbs journal.
You run X right? Well, on a single CPU box, your app and the X server constantly vie for the CPU, the app (well, actually xlib) queues up some drawing requests, then the X server takes over the CPU and draws them. Rinse, repeat.
With SMP, the X server gets a CPU, as does the app. Much less context switching, and the cache doesn't get thrashed because the linux scheduler tries to keep processes on the CPU they last ran on.
The old X FAQ actually recommends swaping workstation and $DISPLAY with a coworker on a fast network, to reduce the context switching overhead. You work on her machine, showing up on your local X server, and he does the same.
SMP is the wave of the future. Between the dual celeron board, and $110 P-II 450s, SMP is the way to go for the fastest system available cheap.
the GART acts like a TLB for your AGP video card. It is chipset dependant. Basically, that huge texture you have allocated in your program from 0x4000 to 0x0A000 is, in reality spread all over physical memory in little page sized chunks (like most virtual memory). The GART makes all those little chunks look like a contiguous texture, by mapping the virtual address that the video card has to the various parts of physical memory on the motherboard. I'm not sure how it handles textures that have been paged out to disk, I assume it traps out for software to handle, just like the TLB does, or it may require you to MLOCK_ALL your textures into RAM.
Last I checked, VIA was being very open with the programming info required to operate the GART, but Intel was playing games. This may have changed lately.
Client side java rocks. For webgames: http://kijiki.resnet.gatech.edu/breakout
It crashes Netscape/X though, for Linux, I suggest IBM's JIT or Blackdown/Sun's latest RC: "appletviewer http://kijiki.resnet.gatech.edu/breakout/play.html " and goto the link off the main page to see your highscore.
oops, got a bit more I forgot to attach to that post:
number of lines in the openbsd kernel (wc -l `find/usr/src/sys -name "*.[chsS]"`): ... 1874216 total (and this includes non-working ports)
number of GNU lines (wc -l `find/usr/src/sys/gnu -name "*.[chsS]"`): ... 12004 total
So OpenBSD (the only BSD I have locally, sorry Free and NetBSDers) contains ~ 0.6% of that EVIL, tainted GNU code. Which, in case you're up too late, is 0.1% more lines than BSDed lines in Linux.
In other words, not only are the "Linux is full of BSD code" people idiots, at least OpenBSD contains some of that evil FSF/GNU code.
Note: I run OpenBSD and Linux. I love OpenBSD and think Theo et al are doing a great job. I will not, however, let such foolish statements as "Linux is full of BSD code" pass uncommented. These idiots reflect poorly on the entire free software community, GPLed or BSDed. Please refrain from resorting to lies when advocating your platform of choice, if you insist on advocacy. It undermines your credibility.
yeah, except the ICMP_ECHO_REPLY is the same size as the ECHO_REQUEST you sent. Go read the good prof's write up. It points out that a 29 byte packet gets a 1500 byte reply. So your 33.6 modem could easily fill a T1. Try that with ICMP_ECHO.
Its not as bas as smurf was, but don't write this off.
John Carmack is my hero for one reason only. I don't much like his games, but he is the primary reason I can buy a $120 video card with a ridiculously fast OpenGL driver. Without Carmack, I would either have to smash my head against the incredible SUCK that is direct3d, or spend a whole month's pay on a SGI or Intergraph box.
The kind of realtime needed for video is easily handled by Ingo's small low latency patch, and SCHED_FIFO. The kind of realtime needed for real time audio processing is beyond what UTIME (or KURT) can deliver. You need a sound driver framework for RT/Linux for that, which David Olofson has provided.
So UTIME, while interesting for network traffic analysis applications, is too much for realtime video, and not enough for realtime audio. Two different solutions, each with less overhead in the normal case, are available, and will make their way into the mainline kernel.
While sound is a good example, your mp3 playing is more than handled by soft realtime. No one cares about 50ms delay between hitting pause and the sound stopping. Now if you're using your computer as a DSP effects box, 5ms from input soundcard to output soundcard might well be too much. With RT/Linux and David Olofson's RT/Linux audio drivers, we are only limited by the PCI burst size.
Sub-ms audio processing is now doable on Linux. The supposed "Media OS" can't do that. While the BeOS may still kick Linux around in terms of video, between Ingo's low latency patches, RT/Linux, and the new audio plug-in APIs, Linux is now THE OS for audio, at least from a technical standpoint.
Interesting. Unless the DOS and linux boxes need to by physically seperated, this is precisely what RT/Linux is for. It is basically a simple DOS like environment that runs Linux in whatever time is left over. You can get interrupt response and scheduling very similar to DOS, and communication with tasks in the Linux subenvironment is quite simple using shared memory, or FIFOs. I can't help but think it would be cheaper to just use one machine running RT/Linux unless you already have a large investment in the DOS portion.
RT/Linux in effect gives you two machines, one RT system running a simple (but richer than DOS) environment, and then a normal linux environment.
Slashdot Mirror
I don't know exactly when the change went in. But if its there, you want it. If you need it and don't have it, you'll know because X will be super slow (MIT-SHM obviously relys on SHM working).
echo "none /var/shm shm defaults 0 0" >> /etc/fstab
That should do ya. make sure you use ">>" not ">" or you'll clobber your fstab (that's bad).
Man, trying to secure a httpd written in sh is gonna suck. Just for starters, try:/ ../../../../etc/passwd
http://jester.vip.net.pl:8081/../../../../../..
It also appears you can execute arbitrary commands by changing your reverse DNS to contain the command and '|', ';' and/or '&'.
There is a good reason not to write CGI scripts in shell, and an even better one not to write a whole httpd!
Impressively wrong, for a variety of reasons.
Garbage collection being the most obvious, and the largest.
Take a look at Smalltalk: www.squeak.org
everything (and I mean EVERYTHING) is an object. Classes are objects that descend from Class. Defining a subclass of another class entails sending a message (think method call) to the superclass telling it to hand me a subclass that declares x as a class variable, and y as an instance variable, and has the following methods.
Blocks of code are objects. like { code; code; } in java. You want to spawn off a thread? [ code to run in seperate thread. ] createProcess.
that sends the "createProcess" message to the block of code object.
java and C++ look like C with objects strapped on (imagine that) compared to smalltalk.
Of course, I failed to mention that its a pain in the ass, and slow too. =)
huh? so java's "int" primative is now an object? not with any compiler/vm I've ever used. The fact that your code is compiled to bytecode and executed by a VM is just an implementation issue. There can be (and are! towerj and gcj spring to mind) direct to native java compilers.
once you know a few procedural languages, and a few OO languages, and the concepts underlying each, you really should be able to pick up a new (procedural/OO) language in a weekend. The APIs might take longer, but that's not really a language issue.
Now if you know a bunch of procedural and OO languages, and you try to pick up LISP, it might take a little while, but that's because its a different model. Once you know a few functional languages, picking up a new one shouldn't take all that long either.
It would be nice if what you said was true, but its not. pmud is for bronze and earlier powerbooks only. The new firewire powerbook's PMU is unsupported. I think the iBook's PMU is also unsupported, but I am not sure.
To help out the spindown problem, try mounting your partitions noatime. This prevents it from writing to disk every time it accesses any page (even though the page is in cache). This usually lets the system spin down the hard drive for enough time to be worthwhile.
My 500Mhz g3 powerbook gets about 7 hours with both batteries in. Which is excellent considering linux doesn't support the PMU, so the hard drive is always on, the backlight is always on FULL BRIGHTNESS and the sound/ethernet/modem is always on.
Of course, I can't use it on my lap, because like a PIII laptop, it gets pretty hot as you run it.
rc5 (i know, i know) puts it about even with a desktop PIII-650. Which is especially impressive considering that a mobile PIII is slower than a desktop PIII.
I don't know if the price difference is worth it for apple desktop hardware, but for laptops, apple is the only way to go.
heh. believe it or not, some people have a sense of humor. I love it when this flamewar comes up because it gets so ridiculous so quickly.
typing this on a SMP linux box, through an openbsd nat/firewall.
of course, my mocking post was funnier, so neener neener!
99% of the BSDers who slam linux installed linux is 1997, and switched to BSD in 1999 when linux got too popular. Now they need some reason to justify their move, other than "I don't feel 31337 using linux anymore."
The other 1% had their dog run over by linus torvalds when they were younger.
I'd like to take a moment to thank Amazon.com for forcing the issue of patent reform. If they maintain their current rate of ridiculous patenting, the patent office will soon be forced out of their complacent attitudes towards patents on the unpatentable. Without Amazon exploring the frontiers of idiotic patents, this process might takes years longer, making the damage much worse in the long run.
Now back to your regularly scheduled "i've patented xyz" posts.
Issue #310 (March 2000)
"Inside the Bluetooth Wireless Comm Spec"
James Y. Wilson & Jason A. Kronz
Most likely, its not up on ddj.com yet.
Its a short range 2.4Ghz frequency hopping networking protocol. Applications are pretty much: Everythign irda was supposed to do but sucked at + audio distribution (IE, your cell phone turns into a landline phone when you're near your computer) + tons of neat-o new stuff (your palmpilot can dial a number on your cell phone).
There is a reasonably good article about it in the latest Dr. Dobbs journal.
You run X right? Well, on a single CPU box, your app and the X server constantly vie for the CPU, the app (well, actually xlib) queues up some drawing requests, then the X server takes over the CPU and draws them. Rinse, repeat.
With SMP, the X server gets a CPU, as does the app. Much less context switching, and the cache doesn't get thrashed because the linux scheduler tries to keep processes on the CPU they last ran on.
The old X FAQ actually recommends swaping workstation and $DISPLAY with a coworker on a fast network, to reduce the context switching overhead. You work on her machine, showing up on your local X server, and he does the same.
SMP is the wave of the future. Between the dual celeron board, and $110 P-II 450s, SMP is the way to go for the fastest system available cheap.
the GART acts like a TLB for your AGP video card. It is chipset dependant. Basically, that huge texture you have allocated in your program from 0x4000 to 0x0A000 is, in reality spread all over physical memory in little page sized chunks (like most virtual memory). The GART makes all those little chunks look like a contiguous texture, by mapping the virtual address that the video card has to the various parts of physical memory on the motherboard. I'm not sure how it handles textures that have been paged out to disk, I assume it traps out for software to handle, just like the TLB does, or it may require you to MLOCK_ALL your textures into RAM.
Last I checked, VIA was being very open with the programming info required to operate the GART, but Intel was playing games. This may have changed lately.
Client side java rocks. For webgames: http://kijiki.resnet.gatech.edu/breakout
l " and goto the link off the main page to see your highscore.
It crashes Netscape/X though, for Linux, I suggest IBM's JIT or Blackdown/Sun's latest RC: "appletviewer http://kijiki.resnet.gatech.edu/breakout/play.htm
Enjoy!
oops, got a bit more I forgot to attach to that post:
/usr/src/sys -name "*.[chsS]"`):
/usr/src/sys/gnu -name "*.[chsS]"`):
number of lines in the openbsd kernel (wc -l `find
...
1874216 total (and this includes non-working ports)
number of GNU lines (wc -l `find
...
12004 total
So OpenBSD (the only BSD I have locally, sorry Free and NetBSDers) contains ~ 0.6% of that EVIL, tainted GNU code. Which, in case you're up too late, is 0.1% more lines than BSDed lines in Linux.
In other words, not only are the "Linux is full of BSD code" people idiots, at least OpenBSD contains some of that evil FSF/GNU code.
Note: I run OpenBSD and Linux. I love OpenBSD and think Theo et al are doing a great job. I will not, however, let such foolish statements as "Linux is full of BSD code" pass uncommented. These idiots reflect poorly on the entire free software community, GPLed or BSDed. Please refrain from resorting to lies when advocating your platform of choice, if you insist on advocacy. It undermines your credibility.
look, I'll try to make this simple for you. Linux is a kernel. The SLIP, PPP, and qic02 (yay) code is BSD derived.
.c and 2 .h files that contain BSD code to integrate them into linux.)
Lines of code in 2.2.13 (wc -l `find . -iname "*.[chS]"`):
...
1927155 total
Lines of code in files containing ANY BSD code (wc -l `find . -name "*.[chS]" | xargs grep -il 'copyright.*regents'`):
...
11011 total
Sooo.... ~ 0.5% of Linux is BSD derived. Did you have any other stupid claims you wanted shot down?
(Note: This is ignoring the fact that non-BSD code was undoubtedly added to the 6
yeah, except the ICMP_ECHO_REPLY is the same size as the ECHO_REQUEST you sent. Go read the good prof's write up. It points out that a 29 byte packet gets a 1500 byte reply. So your 33.6 modem could easily fill a T1. Try that with ICMP_ECHO.
Its not as bas as smurf was, but don't write this off.
John Carmack is my hero for one reason only. I don't much like his games, but he is the primary reason I can buy a $120 video card with a ridiculously fast OpenGL driver. Without Carmack, I would either have to smash my head against the incredible SUCK that is direct3d, or spend a whole month's pay on a SGI or Intergraph box.
Oh yeah, Chris Hecker gets points too.
The kind of realtime needed for video is easily handled by Ingo's small low latency patch, and SCHED_FIFO. The kind of realtime needed for real time audio processing is beyond what UTIME (or KURT) can deliver. You need a sound driver framework for RT/Linux for that, which David Olofson has provided.
So UTIME, while interesting for network traffic analysis applications, is too much for realtime video, and not enough for realtime audio. Two different solutions, each with less overhead in the normal case, are available, and will make their way into the mainline kernel.
While sound is a good example, your mp3 playing is more than handled by soft realtime. No one cares about 50ms delay between hitting pause and the sound stopping. Now if you're using your computer as a DSP effects box, 5ms from input soundcard to output soundcard might well be too much. With RT/Linux and David Olofson's RT/Linux audio drivers, we are only limited by the PCI burst size.
Sub-ms audio processing is now doable on Linux. The supposed "Media OS" can't do that. While the BeOS may still kick Linux around in terms of video, between Ingo's low latency patches, RT/Linux, and the new audio plug-in APIs, Linux is now THE OS for audio, at least from a technical standpoint.
Ah, thanks for the dose of enlightenment. Live and learn.
Interesting. Unless the DOS and linux boxes need to by physically seperated, this is precisely what RT/Linux is for. It is basically a simple DOS like environment that runs Linux in whatever time is left over. You can get interrupt response and scheduling very similar to DOS, and communication with tasks in the Linux subenvironment is quite simple using shared memory, or FIFOs. I can't help but think it would be cheaper to just use one machine running RT/Linux unless you already have a large investment in the DOS portion.
RT/Linux in effect gives you two machines, one RT system running a simple (but richer than DOS) environment, and then a normal linux environment.
How much do you want to bet that this gets fixed in Win2k?
Posted with Mozilla M12!