And what's the use of building yet another gadget-on-wheels that doesn't do all that much, but can be called a "robot". Seriously it's the robotics equivalent to 'hello world'. This kind of thing worries me in all seriousness; there are dozens of worthwhile projects people can spend their time on, coding and debugging work for some of the big OSS jobs that can be really worthwhile!.
So we can load linux on it!
Say what you will about the simplicity of the project. I'm just glad to finally have a cheap supply of motors. Those suckers are expensive!
And with a +/- 12V drive, all ready to go. I'm slapping myself for not having thought of it first.
Frankly OSS isn't about developing products, its about developing the building blocks for other people's project, who in turn have their ideas icorporated into a more sophisticated procect, and so on.
Re:I knew I should have saved that spam
on
Floppy the Robot
·
· Score: 1
Now what could you do with thost ancient 8" drives. (You could see them in action in computer classics like War Games.)
Re:Make sure to use broken drive...
on
Floppy the Robot
·
· Score: 1
I was picturing a large steel cylinder with hoseses sticking out personally.
That information has to come from somewhere. Whether that somewhere is on the internet, or cached on your hard drive, it now exists in a structured format ready to be sifted.
Given how every security system the boys at Redmond produce leaks information like a spilled bottle of cheap perfume, it won't take the hounds very long to track the scent.
I use Tcl/Tk like its my job, but to do nifty features for kiosk applications you end up making some REALLY funky calls to Dll's. Exotic things like turning the computer off. You are technically tricking the UI into thinking someone clicked "Start->Shutdown", but why do I have to do that through a GUI!
Unless you tell the user WHAT the security is, they will make poor decisions about what to do with the data.
Users always want to have it both ways. They want to be able to tweak their system, and install all sorts of crap. The want to file information any which way on their local workstation. At the same time they want it to be your problem when things blow up, the data is gone.
Computers are just like driving. You may not be able to field strip an engine, but you should understand the physics enough to leave following distance, brake before turning, etc. You also need to take the sucker in for oil changes, inspections, and when things sound funny.
Of course, any mechanic will tell you that your average consumer does a crappy job at that too.
I have an old CTX laptop that draws a pretty moire pattern every time I boot X. It's up there for only a few seconds, and it looks MOSTLY like modern art.
It changes enough for me to see that something is updating that area of memory. It's just similar enough for me to know that it IS the same section of memory.
The problem with a single sign-on system is not conceptual. Single sign-ons are great for Intranets.
You can design the system to be virtually crack proof.
The issue is that you now have the entire user-base of the world trying to live as one big happy family on a central authentication server-farm somewhere. No matter how much you grow that server-farm, you are going to run up against some limitation to performance. If the central server is overwhelmed EVERYTHING attached to it slows to a crawl.
This is why NT domains are so pathetically small.
Now to prevent a single point of congestion or failure, you design redundent nodes and/or you start caching information locally.
Replicating information across databases opens you up to corruption (or pollution) in transit. If you aren't absolutely paranoid about validating both sides of a conversation, haX0rs can insert their own credentials.
Cached information requires complete trust of the local operating system, all of its binaries, and the network connection between here and the central authenticator. The right magic can insert, spindle, or mutilate credentials in the local cache. (Think stack smashing attacks, spoofing the server, etc.)
Hell, I wrote a website for a volunteer organization with more security than that in my spare time!
I have a Kerberos-like session management system. After authentication, the browser gets a cookie with its authorization ticket. The ticket is surrendered every page view, and validated against a database of open sessions.
No session, expired session, illegal session, go back to the login page. The whole thing is 7000 lines of code in TCL, including my SQL library routines.
Hackers are only an endangered species because it hardly takes a hacker to break MS code these days.
I think the theory is, that by having so much low-hanging fruit, M$ is hoping that the next generation of hackers will be as complacent as the present user base.
Well, at least take the shine off of 0w#!n@ a system. It used to be a challenge. Now its just annoying.
I'll bet they tried to punch english units into the metric equipment. LOL
This should be a case in point about why we should be using the russian equipment. If the space shuttle were 500 KM off, the orbiter would be a pile of debris and the crew likely dead. Only a handful of landing strips exist that can accomodate it, and it comes in so fast you have only a window of a minute or two where it is safe to eject. Too soon and you are going to be torn apart by the wind. Too late, and the shuttle is falling like a brick.
I just realized there is something even more subtle at work.
Under copyright law, you can only claim copyright on the work as a whole. In human-language works, to show copyright violation generally means that you have to demonstrate the work was largely copied from another work. In music cases, they will play the two songs side by side for the jury.
In this case, SCO can't pull so much as the C equivilent of a paragraph out of the work.
To go a step further, the courts are going to insist that SCO FIRST send a notice to the offending parties to cease and desist. Only after the offending party fails to cease and desist will they have any grounds to bring the case to trial.
Despite what some letigious people will tell you, there is a Legal process. You don't just get to escalate the case because you feel like it, or you need to impress your shareholders.
Isn't a cornerstone of our copyright law that the onous is on the publisher to defend his/her rights. I seem to recall a rather sizable claus that nullifies the right to sue on Copyright infringement if no attempt to enforce the copyright had been made in the past.
Or maybe I'm confusing this with Trademarks?
In any case, it isn't like SCO wrote the code. They bought the code, and as I recall, at a bargain basement price. Hardly 1 billion dollars worth of damage.
No it's the company's management trying to figure out a way to eliminate cabbies. Think about it, if they don't have to loiter waiting for a fare, and instead are directed from point to point by central dispatching, you can theoretically do the same work with fewer cabs.
Not only that, but cabs are drawn to people of credit sufficient to be carrying mobile phones.
Except of course:
They are already making money hand over fist
They DON'T pay the cabbies when they aren't collecting fares
From what I understand, the cabbies pay for fuel
Mobile phones are so cheap they are practically giving them away with breakfast cereal.
So my theory doesn't make sense from a business standpoint. But what a great conspiracy though...
Your average consumer is going have 5 or 6 cabs pass them by the time they figure out how the damn thing is going to work.
Plus, once you find the cab, you then have to dig out the phone number.
My experience with Cabs is that you are either 1 block from a main road they frequent, or so far out in the sprawl that you just call the least seedy one in the phone book.
My distribution would be wrapped around 2 concepts:
There is one good way to do things.
That way is through a scriptable interface
The users that don't want to script will be happy to do things on and only one way anyway.
My distro would be built around Tcl/Tk and a Mysql backend. A special Daemon called "Yggdrasil" would store a master scheme that encompasses all of the settings in the machine. A set of scripts would transform data from yggdrasil into the config files needed by individual programs.
Where possible, I would configure/tweak/patch programs to pull information directly from the yggdrasil.
The interface for the system will be 2 parts:
Click and drool
Script and rule
Any non-admin function will have either a Tk script or an html form. Bundled into the system
would be a local web browser for that purpose. I would also have a Tk-based web browser available for use internally.
Admin functions would be script only, though repetive tasks could be made into a Tk script (ie the make xconfig function for the Kernal, which incidentally IS a tk script.) I would design the whole system to use one and only one scripting language: TCL, with the object oriented Incremental TCL extension.
While that would involve converting over a lot of useful perl and bash scripts that are in common use, it would also get rid of a lot of duplication between them.
Over time the distribution would develop a massive library of UI/Admin functions. This library would be maintained like GLIBC or the kernel by a central bunch of busybodies like myself.
Ah but you forget: the real power of X is IN the fact that it was designed for the network.
Why spend $1000 bucks for a tablet PC when you can spend $50 for an old thinkpad, reformat it to run X, and operated it as a remote X terminal for your desktop in another room?
With X you don't need to dick with moron thinks like Virtual Network Console. You are running the GUI for your programs natively across the network.
And frankly the human eye only sees 12 frames per second. That's it. Movies are 24 frames to get above the Nyquest rate and prevent aliasing. Beyond 24 frames per second any improvement in performance is really in your head.
I measure performance by what I can do that is NOT in the specs.
Hell, how about we ditch hard drives and go back to floppy disks while we are at it.
Slashdot Mirror
So we can load linux on it!
Say what you will about the simplicity of the project. I'm just glad to finally have a cheap supply of motors. Those suckers are expensive! And with a +/- 12V drive, all ready to go. I'm slapping myself for not having thought of it first.
Frankly OSS isn't about developing products, its about developing the building blocks for other people's project, who in turn have their ideas icorporated into a more sophisticated procect, and so on.
Now what could you do with thost ancient 8" drives. (You could see them in action in computer classics like War Games.)
Ack... flasback to EE control simulatutions ...
Hell my 2000 servers are very stable, at least with the feet out.
(reboot)
mkfs /dev/hda1
Ack... must not remember ... need Usenet mental brillo pad
Didn't I have to give up morals with Licensing 6.0?
They will call it ... the net Condom.
That information has to come from somewhere. Whether that somewhere is on the internet, or cached on your hard drive, it now exists in a structured format ready to be sifted.
Given how every security system the boys at Redmond produce leaks information like a spilled bottle of cheap perfume, it won't take the hounds very long to track the scent.
I use Tcl/Tk like its my job, but to do nifty features for kiosk applications you end up making some REALLY funky calls to Dll's. Exotic things like turning the computer off. You are technically tricking the UI into thinking someone clicked "Start->Shutdown", but why do I have to do that through a GUI!
Users always want to have it both ways. They want to be able to tweak their system, and install all sorts of crap. The want to file information any which way on their local workstation. At the same time they want it to be your problem when things blow up, the data is gone.
Computers are just like driving. You may not be able to field strip an engine, but you should understand the physics enough to leave following distance, brake before turning, etc. You also need to take the sucker in for oil changes, inspections, and when things sound funny.
Of course, any mechanic will tell you that your average consumer does a crappy job at that too.
It changes enough for me to see that something is updating that area of memory. It's just similar enough for me to know that it IS the same section of memory.
You can design the system to be virtually crack proof.
The issue is that you now have the entire user-base of the world trying to live as one big happy family on a central authentication server-farm somewhere. No matter how much you grow that server-farm, you are going to run up against some limitation to performance. If the central server is overwhelmed EVERYTHING attached to it slows to a crawl.
This is why NT domains are so pathetically small.
Now to prevent a single point of congestion or failure, you design redundent nodes and/or you start caching information locally.
Replicating information across databases opens you up to corruption (or pollution) in transit. If you aren't absolutely paranoid about validating both sides of a conversation, haX0rs can insert their own credentials.
Cached information requires complete trust of the local operating system, all of its binaries, and the network connection between here and the central authenticator. The right magic can insert, spindle, or mutilate credentials in the local cache. (Think stack smashing attacks, spoofing the server, etc.)
I have a Kerberos-like session management system. After authentication, the browser gets a cookie with its authorization ticket. The ticket is surrendered every page view, and validated against a database of open sessions.
No session, expired session, illegal session, go back to the login page. The whole thing is 7000 lines of code in TCL, including my SQL library routines.
Think: someone we paid to develope M$'s system.
I think the theory is, that by having so much low-hanging fruit, M$ is hoping that the next generation of hackers will be as complacent as the present user base.
Well, at least take the shine off of 0w#!n@ a system. It used to be a challenge. Now its just annoying.
This should be a case in point about why we should be using the russian equipment. If the space shuttle were 500 KM off, the orbiter would be a pile of debris and the crew likely dead. Only a handful of landing strips exist that can accomodate it, and it comes in so fast you have only a window of a minute or two where it is safe to eject. Too soon and you are going to be torn apart by the wind. Too late, and the shuttle is falling like a brick.
Under copyright law, you can only claim copyright on the work as a whole. In human-language works, to show copyright violation generally means that you have to demonstrate the work was largely copied from another work. In music cases, they will play the two songs side by side for the jury.
In this case, SCO can't pull so much as the C equivilent of a paragraph out of the work.
To go a step further, the courts are going to insist that SCO FIRST send a notice to the offending parties to cease and desist. Only after the offending party fails to cease and desist will they have any grounds to bring the case to trial.
Despite what some letigious people will tell you, there is a Legal process. You don't just get to escalate the case because you feel like it, or you need to impress your shareholders.
Isn't a cornerstone of our copyright law that the onous is on the publisher to defend his/her rights. I seem to recall a rather sizable claus that nullifies the right to sue on Copyright infringement if no attempt to enforce the copyright had been made in the past.
Or maybe I'm confusing this with Trademarks?
In any case, it isn't like SCO wrote the code. They bought the code, and as I recall, at a bargain basement price. Hardly 1 billion dollars worth of damage.
The fact that a) they were looking for it and b) found it, leads me to suspect it might (assuming it exists at all) be SCO or someone at SCO.
That's the beauty of open-source. It's wide open, and well documented.
No it's the company's management trying to figure out a way to eliminate cabbies. Think about it, if they don't have to loiter waiting for a fare, and instead are directed from point to point by central dispatching, you can theoretically do the same work with fewer cabs.
Not only that, but cabs are drawn to people of credit sufficient to be carrying mobile phones.
Except of course:
- They are already making money hand over fist
- They DON'T pay the cabbies when they aren't collecting fares
- From what I understand, the cabbies pay for fuel
- Mobile phones are so cheap they are practically giving them away with breakfast cereal.
So my theory doesn't make sense from a business standpoint. But what a great conspiracy though...Your average consumer is going have 5 or 6 cabs pass them by the time they figure out how the damn thing is going to work.
Plus, once you find the cab, you then have to dig out the phone number.
My experience with Cabs is that you are either 1 block from a main road they frequent, or so far out in the sprawl that you just call the least seedy one in the phone book.
My distro would be built around Tcl/Tk and a Mysql backend. A special Daemon called "Yggdrasil" would store a master scheme that encompasses all of the settings in the machine. A set of scripts would transform data from yggdrasil into the config files needed by individual programs.
Where possible, I would configure/tweak/patch programs to pull information directly from the yggdrasil.
The interface for the system will be 2 parts:
- Click and drool
- Script and rule
Any non-admin function will have either a Tk script or an html form. Bundled into the system would be a local web browser for that purpose. I would also have a Tk-based web browser available for use internally.Admin functions would be script only, though repetive tasks could be made into a Tk script (ie the make xconfig function for the Kernal, which incidentally IS a tk script.) I would design the whole system to use one and only one scripting language: TCL, with the object oriented Incremental TCL extension.
While that would involve converting over a lot of useful perl and bash scripts that are in common use, it would also get rid of a lot of duplication between them. Over time the distribution would develop a massive library of UI/Admin functions. This library would be maintained like GLIBC or the kernel by a central bunch of busybodies like myself.
Why spend $1000 bucks for a tablet PC when you can spend $50 for an old thinkpad, reformat it to run X, and operated it as a remote X terminal for your desktop in another room?
With X you don't need to dick with moron thinks like Virtual Network Console. You are running the GUI for your programs natively across the network.
And frankly the human eye only sees 12 frames per second. That's it. Movies are 24 frames to get above the Nyquest rate and prevent aliasing. Beyond 24 frames per second any improvement in performance is really in your head.
I measure performance by what I can do that is NOT in the specs.
Hell, how about we ditch hard drives and go back to floppy disks while we are at it.