Yes, there's a lot of software that requires a reboot while using Linux distribution. I'll summarize it in three words: The Linux Kernel. That's right, the only reason you'd have to reboot your computer is to upgrade the kernel. Name another "reason", and I bet you can do that just fine in userland without rebooting.
"Rebooting" is a red herring. I can obviously switch to run level 1 and do pretty much anything (short of changing the kernel), but I've killed off my computer's functionality. At that point my escape from my BIOS's POST sequence is a little Pyrrhic.
For instance, if I want to upgrade my X server, I have to kill every (non-console) program I'm using. Yeah, sshd is still up and running, but I don't run a server box, I run a workstation, so I could really care less.(If your box is primarily a network server, you're not upgrading the X server anyway; you're upgrading some network service, and the loss of *relevant* functionality is similar. I tend to segregate my servers from my workstations; if you just have one machine doing it all you might appreciate the fact that your friends can still download your mp3s while your productivity drops to zero.)
This is similar to how kids claim that their super-stable Linux box has enjoyed 14 months of uptime while their Windows box crashes weekly. Maybe so, but if your window manager or web browser crashes three times a day under Linux (not too unlikely), it has a lot more of a negative impact on your productivity and pisses you off a lot more than having to sit through a POST once in a while.
I obviously agree that Linux is lightyears ahead of Windows in terms of the granularity of service disruptions imposed on you by upgrades. I just wanted to rant a little;)
My wife's major reaction to Tomb Raider was: "With breasts that big, why don't they bounce around more?"
Actually, I remember playing a playstation game a few years back that had a checkbox in its options screen that let you turn bouncing boobies on and off.
And when then bounced, they bounced wildly and flagrantly. I can just imagine the meetings in which this feature was discussed...
Anyone remember the name of the game? It was some fighting game, if I remember correctly.
I'm sure lots of lines of Cobol are still being written behind closed doors, in dirty little rooms filled with sterile programmers and clamorous machines, but I wouldn't offer that as an argument for its relevance (or its superiority over Java). Popularity is often a red herring in a debate of merits; if it were one we bought into, we'd all be running Windows.
Whether Xt is still important/relevant is debatable. Heck, people argue that X is antiquated and not relevant to modern networks and desktop systems.
Ultimately, though, Qt and GTK/GNOME are in their infancy compared to Motif, as Fountain points out. The moral of the interview, component models and all aside, is that, yes, Motif is not dead, but, yes, it's stake is being usurped by the next generation. My grandma writes Motif.
Personally, my favorite quote in the interview is, "There are things Qt in particular does better than Motif: it is nicer to program with, for example."
Oh yeah, my grandma's dead, by the way.
Re:What's next, royalties when I whistle alone?
on
Ring-Tone Royalties
·
· Score: 2
Should I have to pay... if I use a trademark in an irrelevant sentence?
No, the scope of trademarks is generally limited to the relevant market space. You could open a chain of McDonald's Pet Stores without being sued by the fast food chain. Or you could say, "Gee, McDonald's makes some really shitty tractors."
This may sound shockingly capitalistic and probably isn't the sort of answer you wanted, but just sell them.
My roommates and I accumulated a few modems that we got for free when switching ISPs. We sold them on eBay. If I recall, the last one fetched $120+. I'm sure with enough hacking you could make the status lights blink to the beat of your MP3s or something like that, but I doubt you'll come up with anything as nice as the feel of $400 in your pocket.
Stanford's Graphics Lab's WireGL project is quite a bit cooler than this, in my opinion. I saw a demo of Q3A running on a large tiled display there last month, but that's not the goal...
The point of the project is to develop "a new distributed graphics system that is designed to allow an application to render to a large, tiled display." It is an OpenGL implementation that allows a cluster of one or more machines to render to a tiled display with one or more tiles. So the system allows a cluster of N computers to render a single image, and also allows one computer to render to a tiled display, and also allows N computers to render to M displays in a tiled display.
And, of course, it's OpenGL, so you can put together a rad tiled Quake demo just as easily as you can put together a rad JoesStupidOpenGLTestGame demo.
Eventually, you will reach a single connection on the path that leads to the machine you are looking for. Many providers have redundant connection to the backbones, but, for example, there is only 1 connection from them to you.
Where I work we use two providers. Redundancy in a company's ISPs/backbone connectivity is a reasonable and, depending on your needs, essential.
If you're sitting at home with only one ISP (which is expected), then you should just recognize and accept that having a single point of failure on your end is a fact of life on the consumer end of the commodity Internet. When I'm sitting at home, my power supply and hard drive and network card are all single points of failure as far as my network access is concerned, but I can live with that.
In order for multicasting to make sense, you have to assume that many people downstream of the signal are watching the exact same content exactly in sync (presumably live content) in the same format.
As gets mentioned here from time to time, Digital Fountain addresses (or endeavors to address) the "recipients in sync" problem.
I'd be surprised if multicasting ever comes into very wide use; since the situations that it's useful under are limited...
Where I work, many of us kids like to listen to streaming radio broadcasts. We've been criticized for the strain we put on our Internet connection, and it's a valid point. Often several of us are listening to the same shoutcast stream (or whatever) at the same time, and it seems kinda silly that we consume N * 50-100kbps of bandwidth to receive the same content. But, hey, this is just a personal way in which multicast could help my life.
When most people think of multicast they think of 1-to-many transmission. There are also lots of applications involving many-to-many transmission. Chat is an obvious one; chat becomes particularly well suited for multicast when you're dealing with voice chat rather than text. A more interest application is in networked virtual environments (less grandiloquently, games). A couple other fellows and I wrote the networking part of an NVE that used many-to-many multicast: the world was partitioned into octrees, and each octree was assigned a multicast group. Octree nodes split and merged based on traffic, and there were different levels of groups for messages of different levels of detail (e.g., toe movements vs. explosions). (Well, this was the plan; we didn't finish all of it, but it was a cool demo). Peer-to-peer NVEs have many advantages over client-server systems, including reduced (and hopefully optimally minimal) latency and natural scalability. This book provides an overview of the subject, but there are many papers out there that are more in-depth and informative.
Finally, check out Kevin Almeroth's research in multicast applications. He has several good survey papers that address your synchronized play out gripe and explore the gamut of potential multicast applications.
Dave Wagner at Berkeley published info about weaknesses in 802.11 several months earlier.
Re:What's it good for if your friends don't have o
on
Update From Cray World
·
· Score: 2
But whom can you connect your supercomputer to? Chances are, it's the only one of its kind on the block. You don't see the local knitting guild or mall-walkers' club investing in a supercomputer. You see them investing in a robust NT-server/WinME-client setup.
The problem with universally applying an MCAST-type solution to the internet is that the internet is not like TV and radio: the internet is supposed to be content-on-demand. If you turn on your TV five minutes before a show, you can't start watching it early; simlarily, if you tune in five minutes late you can't start back at the beginning.
No way. While cat and echo are both pretty much functionally equivalent cryptography suites, I'd have to say that echo's user interface is far superior.
When I'm inputting a lengthy chunk of ciphertext into echo's decryption engine, I rely heavily on its advanced editing capabilities. If I discover a typo at the beginning of my inputted ciphertext, for instance, I can hit control-A, and echo jumps me back to the beginning of the line, where I'm just a few characters away from my error. If I try that in cat, I get:
$ cat
mmonkey boy^A^A^A
What the hell is that? I'm sure the mathematicians and programmers who wrote cat were smart people, but why couldn't they spend a little extra time incorporating echo-style advanced editing capabilities?
And while we're on the topic of cat's user interface, what's up with it not exiting? After I decrypt something in echo, it drops me back to my command prompt, where I can quickly email the decrypted message to my cohorts. Cat, on the other hand, makes you do some control-C or control-D mumbo jumbo for no apparent reason.
To each his own, whatever floats your boat, yada yada, but I prefer echo's user friendliness. Comparing echo to cat is like comparing Microsoft Windows to Microsoft DOS.
Besides, you didn't invent that cipher: my computer came with a decryption utility for it. I don't remember exactly what it's called... I'll have to skim through some man pages. I think it's like "echo" or something. Maybe some of the crypto-heads on/. can reply with the exact name. It's GPL'd, too, if I remember correctly.
I work for a startup that's been around for a few years. When we started out, everything ran on MySQL on Linux boxes. That worked fine for a while, until the load on the database increased and we found out the hard way that MySQL didn't scale to meet our needs.
MySQL also supports an annoyingly incomplete subset of the SQL spec and of our (and my) required features. I need transactions. Period. (Please, none of the "transactions [as well as unsupported feature X] are unnecessary" arguments that proliferate everytime the MySQL debate pops up on/.). I needed row locking when MySQL didn't support it. Period.
Today we run on Oracle on Sun servers. Oracle doesn't have alpha transaction support. Oracle on Sun servers doesn't have scalability problems. Oracle offers proven, out of the box failover support. Oracle brings a DBA with letters after his name who knows all the dirty little corners of Mr. Ellison's weathered and polished computer program.
But all the developers still run their development systems on MySQL, 'cuz the Oracle client sucks ass:)
And the other thing - how does this releate to PVM, MPI and other parallell libraries?
MPI, PVM, et al are libraries that parallelized programs can use for inter-node communication.
Sun's Grid Engine is basically a queuing system. To quote Sun's website: "The basis for load management is the batch queuing mechanism. In the normal operation of a cluster, if the proper resources are not currently available to execute a job, then the job is queued until the resources are available. Load management further enhances batch queuing by monitoring host computers in the cluster for load conditions allowing additional utilization of resources."
Grid Engine, however, seems to be designed to run single-node computations; the website mentions nothing about queuing a job for execution on N machines. This is a major distinction from queuing systems in traditional parallel machines and clusters, where you tell the queuer to run your job on N nodes, and when N nodes are available, it runs N copies of your program simultaneously on those nodes.
So, your PVM/MPI/etc. programs won't be able to run parallelly on Grid Engine, because traditional parallel programs assume a tightly coupled network of processors (or processes) that are all running your code simultaneously, and Grid Engine doesn't provide for this. Grid Engine lends itself more to things that can be done by machines independently, like seti@home.
I used to work on a project at UCSB called Javelin: "Javelin is a Java-based infrastructure for global computing". It's presently a bit more academic than practical, but it seems to fit the bill of what you're looking for fairly precisely. It's a bit better than, for example, seti@home in that it supports more tightly coupled computations (e.g., branch-and-bound). Currently, Javelin supports:
piecework computations, where a large chunk of work can be split into smaller chunks, and
branch-and-bound computations, like the travelling salesman problem
, but work is in progress on a version with a more general computational model that supports computations with arbitrary DAGs for task creation and data dependencies (a la Cilk).
It's highly fault tolerant (uses eager scheduling) and load balanced (uses work stealing).
I like Fascism. Fascism keep me safe and happy.
on
The Unblinking Eye
·
· Score: 3
Great quote from the article:
Oakland Raiders Senior Assistant Bruce Allen agreed with the need.
"Whatever they want to do to protect this country, I'm for. . . . So anything we can do to help, I can't imagine anyone disagreeing with that."
Riiiight... "whatever they want to do to protect this country..." Let's just implant microchips in everyone and track their every move. Let's start with Oakland Raiders Senior Assistant Bruce Allen, cuz that quote just scared the hell out of me, and I'd like to know when he comes within 100 miles of me.
Ok. We have proof that slashdot is not a geeksite. Commands like:
find . -print > file ; grep string file , or
ls -lR > file | grep string
don't fill me with a warm fuzzy glow. To find a string in a file, use:
It doesn't fill me with a warm fuzzy glow either.
The first example doesn't look for a string in a file; it looks for a string in the filenames that find returns.
The second example doesn't really do anything other than redirect ls's output to a file; grep never gets run on anything other than an empty standard input stream. For instance, try
echo monkey > file | wc -c
and you'll see that the piped command is executed, but with no input. Which is why God gave us tee.
So, yes,/. isn't a geeksite after all.
To find a string in a file, use:
find . -print | xargs grep string (works on just about anything), find | xargs grep string (works with Gnu find), or rgrep string. (works with rgrep, but rgrep is ugly).
Why use xargs? This is just equivalent to backquotes, which do the job without invoking another program:
grep -s string `find`
(with . -print if your find is bitchy, without -s depending on your grep, etc.). But, of course, it's all about the rgrep.
Slashdot Mirror
Mozilla crashes quite a bit. Enlightenment crashes none-too-infrequently on me, too.
"Rebooting" is a red herring. I can obviously switch to run level 1 and do pretty much anything (short of changing the kernel), but I've killed off my computer's functionality. At that point my escape from my BIOS's POST sequence is a little Pyrrhic.
For instance, if I want to upgrade my X server, I have to kill every (non-console) program I'm using. Yeah, sshd is still up and running, but I don't run a server box, I run a workstation, so I could really care less.(If your box is primarily a network server, you're not upgrading the X server anyway; you're upgrading some network service, and the loss of *relevant* functionality is similar. I tend to segregate my servers from my workstations; if you just have one machine doing it all you might appreciate the fact that your friends can still download your mp3s while your productivity drops to zero.)
This is similar to how kids claim that their super-stable Linux box has enjoyed 14 months of uptime while their Windows box crashes weekly. Maybe so, but if your window manager or web browser crashes three times a day under Linux (not too unlikely), it has a lot more of a negative impact on your productivity and pisses you off a lot more than having to sit through a POST once in a while.
I obviously agree that Linux is lightyears ahead of Windows in terms of the granularity of service disruptions imposed on you by upgrades. I just wanted to rant a little ;)
Can someone please enlighten me as to what "scourge celebre" is?
Actually, I remember playing a playstation game a few years back that had a checkbox in its options screen that let you turn bouncing boobies on and off.
And when then bounced, they bounced wildly and flagrantly. I can just imagine the meetings in which this feature was discussed...
Anyone remember the name of the game? It was some fighting game, if I remember correctly.
I'm sure lots of lines of Cobol are still being written behind closed doors, in dirty little rooms filled with sterile programmers and clamorous machines, but I wouldn't offer that as an argument for its relevance (or its superiority over Java). Popularity is often a red herring in a debate of merits; if it were one we bought into, we'd all be running Windows.
Whether Xt is still important/relevant is debatable. Heck, people argue that X is antiquated and not relevant to modern networks and desktop systems.
Ultimately, though, Qt and GTK/GNOME are in their infancy compared to Motif, as Fountain points out. The moral of the interview, component models and all aside, is that, yes, Motif is not dead, but, yes, it's stake is being usurped by the next generation. My grandma writes Motif.
Personally, my favorite quote in the interview is, "There are things Qt in particular does better than Motif: it is nicer to program with, for example."
Oh yeah, my grandma's dead, by the way.
No, the scope of trademarks is generally limited to the relevant market space. You could open a chain of McDonald's Pet Stores without being sued by the fast food chain. Or you could say, "Gee, McDonald's makes some really shitty tractors."
Yeah... isn't this every software pirate's argument? "I never would have paid $500 for Photoshop, so they're not losing any money by my piracy."
Can someone explain to me what the subject of this post means?
The FBI: to protect and to server. Their new sysadmin duties might explain their proclivity for installing unrequested RAID arrays.
My roommates and I accumulated a few modems that we got for free when switching ISPs. We sold them on eBay. If I recall, the last one fetched $120+. I'm sure with enough hacking you could make the status lights blink to the beat of your MP3s or something like that, but I doubt you'll come up with anything as nice as the feel of $400 in your pocket.
The point of the project is to develop "a new distributed graphics system that is designed to allow an application to render to a large, tiled display." It is an OpenGL implementation that allows a cluster of one or more machines to render to a tiled display with one or more tiles. So the system allows a cluster of N computers to render a single image, and also allows one computer to render to a tiled display, and also allows N computers to render to M displays in a tiled display.
And, of course, it's OpenGL, so you can put together a rad tiled Quake demo just as easily as you can put together a rad JoesStupidOpenGLTestGame demo.
No HMDs, though.
Where I work we use two providers. Redundancy in a company's ISPs/backbone connectivity is a reasonable and, depending on your needs, essential.
If you're sitting at home with only one ISP (which is expected), then you should just recognize and accept that having a single point of failure on your end is a fact of life on the consumer end of the commodity Internet. When I'm sitting at home, my power supply and hard drive and network card are all single points of failure as far as my network access is concerned, but I can live with that.
Well, it's also comment #7, so redundant seems reasonable...
As gets mentioned here from time to time, Digital Fountain addresses (or endeavors to address) the "recipients in sync" problem.
I'd be surprised if multicasting ever comes into very wide use; since the situations that it's useful under are limited...
Where I work, many of us kids like to listen to streaming radio broadcasts. We've been criticized for the strain we put on our Internet connection, and it's a valid point. Often several of us are listening to the same shoutcast stream (or whatever) at the same time, and it seems kinda silly that we consume N * 50-100kbps of bandwidth to receive the same content. But, hey, this is just a personal way in which multicast could help my life.
When most people think of multicast they think of 1-to-many transmission. There are also lots of applications involving many-to-many transmission. Chat is an obvious one; chat becomes particularly well suited for multicast when you're dealing with voice chat rather than text. A more interest application is in networked virtual environments (less grandiloquently, games). A couple other fellows and I wrote the networking part of an NVE that used many-to-many multicast: the world was partitioned into octrees, and each octree was assigned a multicast group. Octree nodes split and merged based on traffic, and there were different levels of groups for messages of different levels of detail (e.g., toe movements vs. explosions). (Well, this was the plan; we didn't finish all of it, but it was a cool demo). Peer-to-peer NVEs have many advantages over client-server systems, including reduced (and hopefully optimally minimal) latency and natural scalability. This book provides an overview of the subject, but there are many papers out there that are more in-depth and informative.
Finally, check out Kevin Almeroth's research in multicast applications. He has several good survey papers that address your synchronized play out gripe and explore the gamut of potential multicast applications.
Dave Wagner at Berkeley published info about weaknesses in 802.11 several months earlier.
This must be a troll....
Digital Fountain seeks to solve this problem.
No way. While cat and echo are both pretty much functionally equivalent cryptography suites, I'd have to say that echo's user interface is far superior.
When I'm inputting a lengthy chunk of ciphertext into echo's decryption engine, I rely heavily on its advanced editing capabilities. If I discover a typo at the beginning of my inputted ciphertext, for instance, I can hit control-A, and echo jumps me back to the beginning of the line, where I'm just a few characters away from my error. If I try that in cat, I get:
What the hell is that? I'm sure the mathematicians and programmers who wrote cat were smart people, but why couldn't they spend a little extra time incorporating echo-style advanced editing capabilities?
And while we're on the topic of cat's user interface, what's up with it not exiting? After I decrypt something in echo, it drops me back to my command prompt, where I can quickly email the decrypted message to my cohorts. Cat, on the other hand, makes you do some control-C or control-D mumbo jumbo for no apparent reason.
To each his own, whatever floats your boat, yada yada, but I prefer echo's user friendliness. Comparing echo to cat is like comparing Microsoft Windows to Microsoft DOS.
Screw you, I just did.
Besides, you didn't invent that cipher: my computer came with a decryption utility for it. I don't remember exactly what it's called... I'll have to skim through some man pages. I think it's like "echo" or something. Maybe some of the crypto-heads on /. can reply with the exact name. It's GPL'd, too, if I remember correctly.
MySQL also supports an annoyingly incomplete subset of the SQL spec and of our (and my) required features. I need transactions. Period. (Please, none of the "transactions [as well as unsupported feature X] are unnecessary" arguments that proliferate everytime the MySQL debate pops up on /.). I needed row locking when MySQL didn't support it. Period.
Today we run on Oracle on Sun servers. Oracle doesn't have alpha transaction support. Oracle on Sun servers doesn't have scalability problems. Oracle offers proven, out of the box failover support. Oracle brings a DBA with letters after his name who knows all the dirty little corners of Mr. Ellison's weathered and polished computer program.
But all the developers still run their development systems on MySQL, 'cuz the Oracle client sucks ass :)
High school CS department? DEPARTMENT? Where did Timothy go to school? Most high schools are lucky if they just have a programming class.
MPI, PVM, et al are libraries that parallelized programs can use for inter-node communication.
Sun's Grid Engine is basically a queuing system. To quote Sun's website: "The basis for load management is the batch queuing mechanism. In the normal operation of a cluster, if the proper resources are not currently available to execute a job, then the job is queued until the resources are available. Load management further enhances batch queuing by monitoring host computers in the cluster for load conditions allowing additional utilization of resources."
Grid Engine, however, seems to be designed to run single-node computations; the website mentions nothing about queuing a job for execution on N machines. This is a major distinction from queuing systems in traditional parallel machines and clusters, where you tell the queuer to run your job on N nodes, and when N nodes are available, it runs N copies of your program simultaneously on those nodes.
So, your PVM/MPI/etc. programs won't be able to run parallelly on Grid Engine, because traditional parallel programs assume a tightly coupled network of processors (or processes) that are all running your code simultaneously, and Grid Engine doesn't provide for this. Grid Engine lends itself more to things that can be done by machines independently, like seti@home.
- piecework computations, where a large chunk of work can be split into smaller chunks, and
- branch-and-bound computations, like the travelling salesman problem
, but work is in progress on a version with a more general computational model that supports computations with arbitrary DAGs for task creation and data dependencies (a la Cilk).It's highly fault tolerant (uses eager scheduling) and load balanced (uses work stealing).
Oakland Raiders Senior Assistant Bruce Allen agreed with the need.
"Whatever they want to do to protect this country, I'm for. . . . So anything we can do to help, I can't imagine anyone disagreeing with that."
Riiiight... "whatever they want to do to protect this country..." Let's just implant microchips in everyone and track their every move. Let's start with Oakland Raiders Senior Assistant Bruce Allen, cuz that quote just scared the hell out of me, and I'd like to know when he comes within 100 miles of me.
The first example doesn't look for a string in a file; it looks for a string in the filenames that find returns.
The second example doesn't really do anything other than redirect ls's output to a file; grep never gets run on anything other than an empty standard input stream. For instance, try
and you'll see that the piped command is executed, but with no input. Which is why God gave us tee.So, yes, /. isn't a geeksite after all.
Why use xargs? This is just equivalent to backquotes, which do the job without invoking another program: (with . -print if your find is bitchy, without -s depending on your grep, etc.). But, of course, it's all about the rgrep.