A lot of people have said things like "x86 isn't used that much for embedded programming anyway," and that's clearly false.
Generally, the trend in the embedded -- specifically automation and control -- markets, is to move from expensive and non-forward-compatible ASICs and SH processors and the MIPS series to x86 processors. Why, you ask? Because x86-based PLCs can be programmed using a standard compiler, instead of a special cross-compiler like the Green Hill Compiler (which costs a lot).
Did I mention the cross-compilers for SH/MIPS/etc cost a *lot*?
By using x86 one COTS compilers. Conceivably, if you're using COTS equipment for the buses (standard UART, etc.) you could compile applications and OS using VC++, gcc, Turbo C, etc. x86 for embedded/PLC might seem braindead, but the cost savings outweigh the programmer's headache. This is especially true if you're running in real mode and don't have to worry about segmented memory (no matter; most embedded x86 programmers just initialize the segment registers to the same value and the offset registers to MAXINT and in doing so, get a flat memory model)
In addition, x86 is the primary target of VxWorks, UC/OS, and other off-the-shelf operating systems. The advantage to using 3rd party operating systems is, you don't have to spend time and money designing your own to find it incompatible along your product line -- especially if the low end of your product line is an SH processor and the high end is a pentium III. By using x86 for the embedded market, you can cash in on standardized, third party OSes and not have to worry about backwards/forwards compatibility.
So now that I've finished ranting about how x86 is a big cost saver, let's talk about why 486-K6 is important (from AMD's point of view). Let's face it. You couldn't use the athlon to power ANY industrial or consumer appliance -- unless you're talking about an oven. My athlon 1400 hits 55C and that's WITH a FOP38 cooler and four case fans. Air flow issues I may have aside, this is clearly unacceptable for thermostat controls, or assembly line mechanisms, or automotive controls, or space shuttle computers, or smart refrigerators, et al. By having a low-power K6-II (my laptop uses a K6-II/400 and it runs pretty damn cool) one can get optimum performance at a low cost, using very little power. Combine the "low cost/low power draw/reasonable performance" benefit with the "standardized OS/save costs on cross-compilers" benefit and you can see why x86 is compelling for embedded control applications.
Personally, if this is true (I've seen no announcement from AMD proper, only from this forwarded memo), I think it's going to be a big hit for AMD and other companies alike. It's going to be a big hit for AMD because they're going to lose money on a big, if unsexy market (embedded is FAR more important than PCs now, and in the future will be more so). It's going to be a big hit for embedded programmers because Intel will have a monopoly on the x86 embedded market. As more and more managers decide to move from SH/MIPS/Zilog/whatever to x86 so that they can cross-compile from COTS compilers, they're going to be pushing more money into Intel's hands. Intel can then reasonably do some serious price gouging, claiming "it takes extra effort to keep these 386E, etc plants open" even though the plants are a 'sunk cost' in terms of capital.
Well, the men in white coats are ranting... and they have blue faces?
(three tones)
Re:Valuable advice from the future
on
Windows in 2020
·
· Score: -1
Freezing old, obsolete kernels and using them 30 years in the future?
One of the things I've noticed is that so-called "user-friendly" distributions (read: Graphical installer where you can play tetris etc) tend to have more underlying problems under them.
Case in point: Mandrake. While Mandrake is a very friendly distribution, and in fact up until 8.0 was my primary desktop-based solution (I prefer Red Hat, OpenBSD, or OPENSTEP[!] on servers). I've noticed several creeping little problems which show that the Mandrake people are missing little problems in their quest to automate everything.
First example is simple. Mandrake likes to include portsentry with their distributions. With msec greater than or equal to 3, it's also a good idea to have portsentry running. However, portsentry.conf has its default $KILL_ROUTE set to 'ipchains.' Mandrake by default installs iptables (and although the kernel is enabled to allow legacy ipchains, that's not perfect). Red Hat, by contrast, includes portsentry and installs ipchains by default for backwards compatibility. Moreover, portsentry.conf has $KILL_ROUTE set to 'route', which is ideal for backwards compatibility (and hell on your routing tables:) )
As I said, I use Mandrake, and this isn't a bash on mandrake. Solving this problem is simple if you RTFM -- change one line in portsentry.conf. The point is, that Mandrake ISN'T as user-friendly as one thinks it is, if we are to use the 'point and click and forget' paradigm of user-friendliness.
Moving on...
It's other problems like this, little 'tweaks' here without a corresponding 'co-tweak' there, that irritates me about Mandrake. Unresolved issue with PhoenixBIOS and their apmd is another good example. The customized mandrake_desk is very good, until you install a third party RPM which doesn't recognize the format. Whoops! There goes your KDE menu! Looks like you'll have to manually run update-menus! Does a newbie even *know* what that is?
I want to solidly reiterate that I don't mean to bash Mandrake specifically, or say that it's *NOT* user-friendly. As stated before, I use mandrake and I've solved all of these problems. But I had to get under the hood to do so, contrary to the 'click and drool' image Mandrake puts on.
But I digress...
Finally, and I admittedly don't know if this is a consequence of the LSB or not, but I've noticed a large shift away from configurable options in rc scripts to/etc/${PROGRAM_NAME}/ to/etc/sysconfig/${PROGRAM_NAME}. Certain new distributions -- Mandrake and Redhat -- will step this farther and put things like ipchains, iptables, chat, ip-up, ip-down, etc. in/etc/sysconfig/network-scripts, which although good conceptually, isn't where the manpage says they are:)
Overall, for a solid Linux distribution in terms of consistency, I'd say Red Hat only because you can bitch at them if it's their fault (and they generally fix it, despite overwhelming anti-Redhat fervor among the kiddies here). Personally, if you're looking for *simple* consistency, a BSD might do ya some good, where all the rc's are where you think they are.;-)
clone() is NOT portable across different platforms.
PLEASE use pthread_create()!
Let's go over this again. Attack of the pthread_create()s.
There. doesn't that sound better?
Re:KDE 2s2 feature depth is astounding
on
KDE 2.2 Tagged
·
· Score: -1
What I really like about kde2 in general (especially with respect to the autozooming of tasks in kasbar, representing thumbnails on icons, etc.) is that it's everything Enlightmenment tried to be, except with a consistent API behind it. By organizing within the KParts framework, all the bells and whistles E users have come to love now work consistently and uniformly.
It's exactly this uniformity that makes a desktop environment works. The big advantage of Win32 is OLE/DCOM/ActiveX/nameOfTheDay -- the ability to drag one object from one application (a paragraph from Word, for example) and drop it within another (Explorer, Access, Oracle, etc.) This is a significant improvement over, for example, the inconsistent cut and paste behavior between different X toolkits and X itself.
FWIW, I think the next step is to write QT wrappers for the various GTK primitives. When called within a QT environment, GTK applications would have the same behavior as under a QT widget set.
Well, you have to be careful with that. If it's an exploit that nullifies CR2 without damaging the host system (and maybe repairs the system), then such a 'dynamic hotfix' would be a good idea. However, simply DoSing the worm would DoS the host system.. sort of like curing cancer by killing the patient (and in the case of HeLa cells, even that doesn't work)
However, just like any other virus, Code Red can be patched to fix the exploit. CRIII would be out and about, maybe with a new set of bugs, effectively making it polymorphic.
On a purely technical level, I'm hoping that Palm will buy out Be. Be's recent refocus on the embedded/internet appliance market really showcases the advantages of BeOS. Here, a real-time (or at the very least, low-latency) operating system can shine; moreover, since Microsoft hasn't yet conquered the embedded market, the barriers to entry aren't the same as the desktop market.
PalmOS is, IMHO, quite sufficient for the current generation of PDA's. However, as devices become more inclusive (personal organizer + mp3 player + cell phone + web browser) -- in other words, what everyone seems to think of the Star Trek "Tricorder" -- the need for a well architected OS is absolutely necessary.
I'm not one for buzzword compliance, but the fact that be is a modular, OO system will help in portability and tailoring for certain tasks. A PDA without sound hardware, for example, won't need a sound server runtime. Having the sound server be seperate and communicate via a standard API makes it really easy to excise that component without breaking any dependencies.
An area I'd like to see Palm/Be to venture into is programmable logic controllers. By marketing Be's technology, OS, SDK, etc. as a competitor to VxWorks, the move can be made into industrial and automated systems. While this isn't particularly sexy or well-rounded (something that Be strives to be), it's certainly dependable money. Hardware manufacturers such as Siemens, GE, etc. are always looking for something to replace their custom-written, more-spaghetti-than-olive-garden operating systems and applications. While most people associate Be with multimedia, DSP work, et al, the kernel proper can be slimmed down to handle simple serial input-output tasks. Once a hardware client starts to use the software, they're going to grow dependent on it, and that's a steady -- albeit not too grandiose --flow of revenue for Be (and its buyer)
Well, I can tell by the men in white coats encroaching that it's time to stop rambling.
The line about the "reiserfs controversy" irks me. Sounds a little like sensationalism. How is making a (wise) decision not to include reiserfs into the kernel tree a controversy?
To sum up the link, reiserfs has some goofy buffering behavior (among other things), the reiserfs people say "it works better now", Alex Viro points out the fact that the code hasn't been updated in years in some spots (or to paraphrase him, "you don't fix things unless they break compile") and tells the reiser people to clean up their act before distribution on the main tree. Other Linux powers-that-be agree, saying yes, it should be cleaned up, in its current state it's better for 2.5 inclusion.
It is not a controversy when there are options. The reiser people have several choices
They can clean up their code.
They can distribute as a patch seperately.
They can fork their own kernel and distribute with the reiserfs included.
They can fork their own kernel and distribute the reiserfs patch seperately.
All or none of the above.
With so many options I don't understand why it's considered 'controversial' unless/. has been hit by Jon Katz Syndrome. With open source you can solve a controversy before it starts. Scratch your own itch and all that?
That having been said, I am happy to see a (proven) journaling filesystem be put out. I have used SGI's for quite some time and have always been impressed with their filesystem performance. Moreover, in the days of 30,40,70 gigabyte hard drives, fsck times after unplanned power must be kept to a minimum. (Pre-emptive responses to the cluebies who say "if you want to preserve 50 gigs of data, use a UPS": the UPS may blow up too;-)
I also am interested in XFS handling large files (64-bit file support); I work with digital video for streaming, and those files get real large, real fast. Seeing a file larger than 4G will make my day.
I highly recommend anyone, people who agree or disagree with me, download the XFS source and look for themselves. Nothing sexier than looking at lock code for hours on end..;-)
Not to sound cruel or anything, but if she's snake-bit in the forest, you can't get to her in time to help.
The secret is preparation, and (as the previous poster said) contacting a U.S. mission in that country. Tasmania for instance may be wild country, but last I heard Australia had pretty good telecommunications (especially from consulates!)
MEEPT!! was decidedly on-topic in a very off-topic way. (S)he managed to play Devil's advocate in a manner that irritated many GNU or Linux Zealots, and he never was direct about it.
MEEPT!! communicated entirely in dadaistic yet insightful koans. Whereas $GRITSPOST is simply comic relief.
This may sound like a shameless plug but at least it's on topic;-)
I am one of the programmers for The College of William and Mary's student community, The Student Information Network. We've been providing essential student services for over two years (log in as 'guest' and check it out), and we're entirely student run.
Which means, of course, when the time came to run the student elections online, everyone was worried that apathy and ballot stuffing would come to the fore. On February 29, 2000, the entire student body had the chance to vote from any web browser. Needless to say, we had a lot of sleepless nights;-) but we managed to pull off a fair election.
The results were spectacular!
So here were the results
To those who said that voting online was more inconvenient than voting at a dining hall (we set up computer stations at dining halls, and public access computer labs could be used for voting as well) -- we had a 43% voter turnout.
To those who feared ballot stuffing -- We monitored the logs at all times and maintained many many backups of our PGP encrypted database. It was a fair election.
It may be noted humorously that, as befits most college elections, a lot of people ran for positions unopposed -- why fear ballot stuffing then;-)
In conclusion, not only am I showing that online elections are doable, but that they are a pleasure to do. If I'm not mistaken, that makes us the first university to have full, binding student body elections entirely online in the nation. Can someone show a date of such an election earlier than Feb 29, 2000 in case we are wrong? I'm curious.
We now return you to your regularly scheduled grits.
This is nothing new. Back before IBM bought Whistle, the Whistle Interjet ran FreeBSD and tried to convince you that it was an easy to set up server solution with turnkey operation.
For the non-computer-user, that's about right. It's really easy to configure (I researched it once because a family member's business was considering marketing a Linux-based competitor), but if you have the slightest hint of what you are doing, buy your own box;)
Furthermore, I've seen it mentioned on/. before, usually as a quickie or in threads. What short memories everyone has...
But anyone can become a lawyer if they invest in the training and meet the standard. Or more importantly, anyone can run for office -- our system was designed so that the common man had a chance at office, even though this isn't always the case -- and if they get elected, they can make laws.
Think of law as open source via a smaller bazaar than usual; more like the FreeBSD team than the Linux developers. There's a tighter grip on who can make a CVS commit (write and enact legislation) and who can submit patches (judge's precedents), but anyone has access to the law and, provided they go through the proper voting, running for office or law training, change it...
ALthough I use mandrake 7 and enjoy it greatly (as a client machine -- not so much as a server, as I prefer FreeBSD) -- you might want to get the supermount patch from freshmeat.net, and patch it into a vanilla 2.2.14 kernel. It should compile cleanly from that point on.
/* i think we should worry about being accepted before we worry about accepting specific groups of people. besides, i have yet to see an article on how current opensource projects could use a native americans touch. */
"The white man wastes the malloc(). He takes it for his own but does not release it for future generations to use. We of $TRIBE use every part of the stack, and free() it for the future of our children."
That was my first thought. But then I realized, if a kid eats a toy, is it the fault of the toymaker or is it the fault of the parents for raising stupid children?
WHo eats toys?
The mascot itself is probably too large to fit in a mouth, but being foam rubber i think it can be compressed.
Slashdot Mirror
When I saw "Linux Goes to Hollywood" I had this image of a penguin in a scarf pacing around on a stage screaming into a bullhorn.
"Relink.. Don't do it..."
A lot of people have said things like "x86 isn't used that much for embedded programming anyway," and that's clearly false.
Generally, the trend in the embedded -- specifically automation and control -- markets, is to move from expensive and non-forward-compatible ASICs and SH processors and the MIPS series to x86 processors. Why, you ask? Because x86-based PLCs can be programmed using a standard compiler, instead of a special cross-compiler like the Green Hill Compiler (which costs a lot).
Did I mention the cross-compilers for SH/MIPS/etc cost a *lot*?
By using x86 one COTS compilers. Conceivably, if you're using COTS equipment for the buses (standard UART, etc.) you could compile applications and OS using VC++, gcc, Turbo C, etc. x86 for embedded/PLC might seem braindead, but the cost savings outweigh the programmer's headache. This is especially true if you're running in real mode and don't have to worry about segmented memory (no matter; most embedded x86 programmers just initialize the segment registers to the same value and the offset registers to MAXINT and in doing so, get a flat memory model)
In addition, x86 is the primary target of VxWorks, UC/OS, and other off-the-shelf operating systems. The advantage to using 3rd party operating systems is, you don't have to spend time and money designing your own to find it incompatible along your product line -- especially if the low end of your product line is an SH processor and the high end is a pentium III. By using x86 for the embedded market, you can cash in on standardized, third party OSes and not have to worry about backwards/forwards compatibility.
So now that I've finished ranting about how x86 is a big cost saver, let's talk about why 486-K6 is important (from AMD's point of view). Let's face it. You couldn't use the athlon to power ANY industrial or consumer appliance -- unless you're talking about an oven. My athlon 1400 hits 55C and that's WITH a FOP38 cooler and four case fans. Air flow issues I may have aside, this is clearly unacceptable for thermostat controls, or assembly line mechanisms, or automotive controls, or space shuttle computers, or smart refrigerators, et al. By having a low-power K6-II (my laptop uses a K6-II/400 and it runs pretty damn cool) one can get optimum performance at a low cost, using very little power. Combine the "low cost/low power draw/reasonable performance" benefit with the "standardized OS/save costs on cross-compilers" benefit and you can see why x86 is compelling for embedded control applications.
Personally, if this is true (I've seen no announcement from AMD proper, only from this forwarded memo), I think it's going to be a big hit for AMD and other companies alike. It's going to be a big hit for AMD because they're going to lose money on a big, if unsexy market (embedded is FAR more important than PCs now, and in the future will be more so). It's going to be a big hit for embedded programmers because Intel will have a monopoly on the x86 embedded market. As more and more managers decide to move from SH/MIPS/Zilog/whatever to x86 so that they can cross-compile from COTS compilers, they're going to be pushing more money into Intel's hands. Intel can then reasonably do some serious price gouging, claiming "it takes extra effort to keep these 386E, etc plants open" even though the plants are a 'sunk cost' in terms of capital.
Well, the men in white coats are ranting... and they have blue faces?
(three tones)
Freezing old, obsolete kernels and using them 30 years in the future?
You must be working for Debian.
One of the things I've noticed is that so-called "user-friendly" distributions (read: Graphical installer where you can play tetris etc) tend to have more underlying problems under them.
:) )
/etc/${PROGRAM_NAME}/ to /etc/sysconfig/${PROGRAM_NAME}. Certain new distributions -- Mandrake and Redhat -- will step this farther and put things like ipchains, iptables, chat, ip-up, ip-down, etc. in /etc/sysconfig/network-scripts, which although good conceptually, isn't where the manpage says they are :)
;-)
Case in point: Mandrake. While Mandrake is a very friendly distribution, and in fact up until 8.0 was my primary desktop-based solution (I prefer Red Hat, OpenBSD, or OPENSTEP[!] on servers). I've noticed several creeping little problems which show that the Mandrake people are missing little problems in their quest to automate everything.
First example is simple. Mandrake likes to include portsentry with their distributions. With msec greater than or equal to 3, it's also a good idea to have portsentry running. However, portsentry.conf has its default $KILL_ROUTE set to 'ipchains.' Mandrake by default installs iptables (and although the kernel is enabled to allow legacy ipchains, that's not perfect). Red Hat, by contrast, includes portsentry and installs ipchains by default for backwards compatibility. Moreover, portsentry.conf has $KILL_ROUTE set to 'route', which is ideal for backwards compatibility (and hell on your routing tables
As I said, I use Mandrake, and this isn't a bash on mandrake. Solving this problem is simple if you RTFM -- change one line in portsentry.conf. The point is, that Mandrake ISN'T as user-friendly as one thinks it is, if we are to use the 'point and click and forget' paradigm of user-friendliness.
Moving on...
It's other problems like this, little 'tweaks' here without a corresponding 'co-tweak' there, that irritates me about Mandrake. Unresolved issue with PhoenixBIOS and their apmd is another good example. The customized mandrake_desk is very good, until you install a third party RPM which doesn't recognize the format. Whoops! There goes your KDE menu! Looks like you'll have to manually run update-menus! Does a newbie even *know* what that is?
I want to solidly reiterate that I don't mean to bash Mandrake specifically, or say that it's *NOT* user-friendly. As stated before, I use mandrake and I've solved all of these problems. But I had to get under the hood to do so, contrary to the 'click and drool' image Mandrake puts on.
But I digress...
Finally, and I admittedly don't know if this is a consequence of the LSB or not, but I've noticed a large shift away from configurable options in rc scripts to
Overall, for a solid Linux distribution in terms of consistency, I'd say Red Hat only because you can bitch at them if it's their fault (and they generally fix it, despite overwhelming anti-Redhat fervor among the kiddies here). Personally, if you're looking for *simple* consistency, a BSD might do ya some good, where all the rc's are where you think they are.
clone() is NOT portable across different platforms.
PLEASE use pthread_create()!
Let's go over this again. Attack of the pthread_create()s.
There. doesn't that sound better?
What I really like about kde2 in general (especially with respect to the autozooming of tasks in kasbar, representing thumbnails on icons, etc.) is that it's everything Enlightmenment tried to be, except with a consistent API behind it. By organizing within the KParts framework, all the bells and whistles E users have come to love now work consistently and uniformly.
It's exactly this uniformity that makes a desktop environment works. The big advantage of Win32 is OLE/DCOM/ActiveX/nameOfTheDay -- the ability to drag one object from one application (a paragraph from Word, for example) and drop it within another (Explorer, Access, Oracle, etc.) This is a significant improvement over, for example, the inconsistent cut and paste behavior between different X toolkits and X itself.
FWIW, I think the next step is to write QT wrappers for the various GTK primitives. When called within a QT environment, GTK applications would have the same behavior as under a QT widget set.
But then again, I'm just rambling again...
Well, you have to be careful with that. If it's an exploit that nullifies CR2 without damaging the host system (and maybe repairs the system), then such a 'dynamic hotfix' would be a good idea. However, simply DoSing the worm would DoS the host system.. sort of like curing cancer by killing the patient (and in the case of HeLa cells, even that doesn't work)
However, just like any other virus, Code Red can be patched to fix the exploit. CRIII would be out and about, maybe with a new set of bugs, effectively making it polymorphic.
On a purely technical level, I'm hoping that Palm will buy out Be. Be's recent refocus on the embedded/internet appliance market really showcases the advantages of BeOS. Here, a real-time (or at the very least, low-latency) operating system can shine; moreover, since Microsoft hasn't yet conquered the embedded market, the barriers to entry aren't the same as the desktop market.
PalmOS is, IMHO, quite sufficient for the current generation of PDA's. However, as devices become more inclusive (personal organizer + mp3 player + cell phone + web browser) -- in other words, what everyone seems to think of the Star Trek "Tricorder" -- the need for a well architected OS is absolutely necessary.
I'm not one for buzzword compliance, but the fact that be is a modular, OO system will help in portability and tailoring for certain tasks. A PDA without sound hardware, for example, won't need a sound server runtime. Having the sound server be seperate and communicate via a standard API makes it really easy to excise that component without breaking any dependencies.
An area I'd like to see Palm/Be to venture into is programmable logic controllers. By marketing Be's technology, OS, SDK, etc. as a competitor to VxWorks, the move can be made into industrial and automated systems. While this isn't particularly sexy or well-rounded (something that Be strives to be), it's certainly dependable money. Hardware manufacturers such as Siemens, GE, etc. are always looking for something to replace their custom-written, more-spaghetti-than-olive-garden operating systems and applications. While most people associate Be with multimedia, DSP work, et al, the kernel proper can be slimmed down to handle simple serial input-output tasks. Once a hardware client starts to use the software, they're going to grow dependent on it, and that's a steady -- albeit not too grandiose --flow of revenue for Be (and its buyer)
Well, I can tell by the men in white coats encroaching that it's time to stop rambling.
--
So he bitches. The question is, does he get the job done?
The line about the "reiserfs controversy" irks me. Sounds a little like sensationalism. How is making a (wise) decision not to include reiserfs into the kernel tree a controversy?
To sum up the link, reiserfs has some goofy buffering behavior (among other things), the reiserfs people say "it works better now", Alex Viro points out the fact that the code hasn't been updated in years in some spots (or to paraphrase him, "you don't fix things unless they break compile") and tells the reiser people to clean up their act before distribution on the main tree. Other Linux powers-that-be agree, saying yes, it should be cleaned up, in its current state it's better for 2.5 inclusion.
With so many options I don't understand why it's considered 'controversial' unless /. has been hit by Jon Katz Syndrome. With open source you can solve a controversy before it starts. Scratch your own itch and all that?
That having been said, I am happy to see a (proven) journaling filesystem be put out. I have used SGI's for quite some time and have always been impressed with their filesystem performance. Moreover, in the days of 30,40,70 gigabyte hard drives, fsck times after unplanned power must be kept to a minimum. (Pre-emptive responses to the cluebies who say "if you want to preserve 50 gigs of data, use a UPS": the UPS may blow up too ;-)
I also am interested in XFS handling large files (64-bit file support); I work with digital video for streaming, and those files get real large, real fast. Seeing a file larger than 4G will make my day.
I highly recommend anyone, people who agree or disagree with me, download the XFS source and look for themselves. Nothing sexier than looking at lock code for hours on end.. ;-)
RMS aka Richard Stallman had a problem with a printer.
He wanted to fix the printer and needed some source code to make a good driver.
AT&T wouldn't give him the source.
He got mad and founded the GNU project which was open source. A year later (1985) he founded the FSF to help defend and delineate the GNU license.
The rest is history..
Not to sound cruel or anything, but if she's snake-bit in the forest, you can't get to her in time to help.
The secret is preparation, and (as the previous poster said) contacting a U.S. mission in that country. Tasmania for instance may be wild country, but last I heard Australia had pretty good telecommunications (especially from consulates!)
Don't flatter yourself. You're no MEEPT!!
MEEPT!! was decidedly on-topic in a very off-topic way. (S)he managed to play Devil's advocate in a manner that irritated many GNU or Linux Zealots, and he never was direct about it.
MEEPT!! communicated entirely in dadaistic yet insightful koans. Whereas $GRITSPOST is simply comic relief.
go go gadget cluestick
csh has file completion. Hit 'escape' instead of tab.
Just curious --
Was this via the web or using a proprietary telnet/tn3270/etc connection?
This may sound like a shameless plug but at least it's on topic ;-)
I am one of the programmers for The College of William and Mary's student community, The Student Information Network. We've been providing essential student services for over two years (log in as 'guest' and check it out), and we're entirely student run.
Which means, of course, when the time came to run the student elections online, everyone was worried that apathy and ballot stuffing would come to the fore. On February 29, 2000, the entire student body had the chance to vote from any web browser. Needless to say, we had a lot of sleepless nights ;-) but we managed to pull off a fair election.
The results were spectacular!
It may be noted humorously that, as befits most college elections, a lot of people ran for positions unopposed -- why fear ballot stuffing then
In conclusion, not only am I showing that online elections are doable, but that they are a pleasure to do. If I'm not mistaken, that makes us the first university to have full, binding student body elections entirely online in the nation. Can someone show a date of such an election earlier than Feb 29, 2000 in case we are wrong? I'm curious.
We now return you to your regularly scheduled grits.
This is nothing new. Back before IBM bought Whistle, the Whistle Interjet ran FreeBSD and tried to convince you that it was an easy to set up server solution with turnkey operation.
;)
/. before, usually as a quickie or in threads. What short memories everyone has...
For the non-computer-user, that's about right. It's really easy to configure (I researched it once because a family member's business was considering marketing a Linux-based competitor), but if you have the slightest hint of what you are doing, buy your own box
Furthermore, I've seen it mentioned on
But anyone can become a lawyer if they invest in the training and meet the standard. Or more importantly, anyone can run for office -- our system was designed so that the common man had a chance at office, even though this isn't always the case -- and if they get elected, they can make laws.
Think of law as open source via a smaller bazaar than usual; more like the FreeBSD team than the Linux developers. There's a tighter grip on who can make a CVS commit (write and enact legislation) and who can submit patches (judge's precedents), but anyone has access to the law and, provided they go through the proper voting, running for office or law training, change it...
ALthough I use mandrake 7 and enjoy it greatly (as a client machine -- not so much as a server, as I prefer FreeBSD) -- you might want to get the supermount patch from freshmeat.net, and patch it into a vanilla 2.2.14 kernel. It should compile cleanly from that point on.
/* i think we should worry about being accepted before we worry about accepting specific groups of people. besides, i have yet to see an article on how current opensource projects could use a native americans touch. */
"The white man wastes the malloc(). He takes it for his own but does not release it for future generations to use. We of $TRIBE use every part of the stack, and free() it for the future of our children."
What a world we live in. A world where, thanks to litigation, TEACHING YOUR CHILDREN NOT TO EAT THINGS THAT ARE NOT FOOD IS OPTIONAL.
Sometimes I wonder...
That was my first thought. But then I realized, if a kid eats a toy, is it the fault of the toymaker or is it the fault of the parents for raising stupid children?
:-)
WHo eats toys?
The mascot itself is probably too large to fit in a mouth, but being foam rubber i think it can be compressed.
For me it's just a nice dashboard decoration
Has anyone noticed, on the bottom of the foam rubber toy, it says in two languages "Not a Toy"? Any idea why people would put this warning on it?
Bravo! Someone moderate this up to its full 5. =)
Well, presumably if it is open source other people can do the polishing...