Should have mentioned "parental controls"
on
A Babe in Tuxland
·
· Score: 2, Insightful
... like Linux's built-in features to prevent K.D. from accidentally finding sites that aren't age-appropriate, or at least haven't been pre-approved by Mom and Dad.
SCO developers and users will still have the existing and all historical versions of gcc available, and still under the GPL at that.
GCC's removal of SCO support does not violate either 5 or 6: FSF isn't proposing a SCO-specific modification to the GPL, so the LICENSE itself is not going to discriminate against SCO users or developers at all.
Besides, the GPL isn't an open source license, it's a Free Software license...
Hear hear. Having been through LFS myself several times, I'm now a diehard RH fan. There's simply too much work involved in producing a slick, fully functional Linux disto for me to want to do it myself. Not that I *can't* do it, I just prefer to leave it to someone else. Even at the full price of a boxed set, my time is still worth more than that (to me!).
Now, I agree completely that you don't know much about Linux et al until you can LFS it! I just don't want to live that way...:^)
Surveys are exempted because they're an easy way for politicians to stay in touch with their constituents, without, um, *actually* staying in touch with their constituents. No way they're gonna legislate that convenience away!
One more thing. You can believe the hype about GT being a top-tier school. Even in retrospect, I still believe it is. And it's an incredible bargain, too.
I checked it out, and that site sounds like a bunch of freshman whining. I was hearing those same complaints when I was there (BEE '91), all of which are highly overblown.
I lived on-campus all three years I was at GT, and rarely had problems with parking because I didn't try to drive to class (it's only like a mile between the two farthest points on campus anyway), and I did most of my commuting (grocery store, errands, etc.) during off-peak hours. I wasn't always able to park 50 ft. from my dorm, but I was always able to find a spot somewhere.
As for food, I didn't mind it. I ate at Woodruff and the SU regularly, and never had any complaints. They were no Chez Junior's (a local eatery called "Juniors" was), of course, just straight cafeteria fare. When I needed a change, I just hit one of the bazillion off-campus options.
Housing? Be realistic in your expectations, don't go expecting Club Med. It was darned convenient to live on campus, because I didn't give a shit about who my roommate was--- I was so busy with work and classes, I never saw them anyway. The dorms aren't posh, but they're far better than what GTSux makes them out to be. That includes the year I spent in Techwood, a 1940's-era (?) building that was reclaimed from a nearby housing project and turned into student housing.
Now, about academics. I'm a graduate of the engineering school, so I have limited experience in the other schools other than hearsay from fellow dorm-dwellers. But my impression is that their experiences were similar to mine. That includes the Architecture school and College of Computing.
I _never_ felt I was getting shafted, or that the profs were being unreasonable. All the professors uniformly expect you to work hard and to know how to apply the material, not just regurgitate it on a test. If you can do that, then you'll get by just fine. And you _can_ do that, if you put your mind to it. During times I was genuinely trying but struggling, the professors were very supportive.
If, on the other hand, you intend to spend your time at GT living scenes out of Animal House, you're in for trouble. The whiners behind GTSux probably fit into this category.
I would highly recommend GT. I had my share of complaints, same as everyone else (real shortage of parking for students, for example), but overall it's a really good school and a really great experience.
Come prepared to learn! Even now, after more than ten years, I'm finding that the education I received there was more thorough and challenging than a lot of other places.
But the social life sucks. Fortunately, Emory is just down the road, and UGA isn't too far.:^)
Why the hell do we insist on using Intel heat pumps in our laptops anyway?! There are any of a dozen different non-Intel chips that are nearly as fast as a decent P-III (or, at least, from the user's perspective) that don't need heatsinks at all! MIPS, ARM (ok, even StrongARM and XScale), SH,...
Oh, wait, Bill doesn't want to support Windows on those chips. My bad. He'd rather force the rest of the industry and users to deal with crappy, Intel-specific problems like heat and power consumption than construct a product that's actually well-designed and portable. Yea, that's "innovative".
I've got a cerfcube here, it's pretty nice. Their GNU toolchain setup process is kinda brain-dead, but their Linux port isn't too bad. I've heard they're moving to Familiar for their Linux setup, but I haven't taken a look lately to see what progress they've made.
Still, it *is* a StrongARM-powered device. Man, that's one buggy chip! If it didn't have Chipzilla and Micro$oft pushing it so hard, that silicon would have been made into bathroom mirrors a long time ago. Gaaak!
But yea, if you're wanting to get a quick start with embedded Linux, a 'Cube isn't a bad way to go.
Engineers fresh out of school can't handle this simple task on their own?
Nope. And I for one don't have a problem with that.
It's just a hobby for me now, but I can still slay 99% of the 'engineers' out there.
That's exactly the trouble I'm frequently called in to clean up after.
An engineering degree is mostly about training you how to think. You aren't going to learn how to write fault-tolerant code, how to harden a system to survive in an industrial environment, or anything else that's so application and domain specific. Five years just isn't long enough. And with no real practical experience to go along with them, even if you *could* train an undergraduate in those skills, you'd still be wasting your time.
The field of embedded systems is *huge*. It requires continuous effort to stay trained in the latest state of the art as it applies to solving real problems. I'll take a trainable, fresh graduate who realizes he's an idiot, over a garage hacker who thinks that since he can make a few LEDs light up on his Basic STAMP, he's ready to design a diesel engine controller.
I realize that these are sweeping generalizations on my part, ymmv.
A desktop PC is a decent place to start, but it simply can't duplicate all the concerns present in an embedded development environment.
For example, it's relatively straightforward to build a native GNU compiler, but much more difficult to build a cross-compiler (one that produces applications for a different architecture than the one the compiler ran on). Unless your embedded system is based on a PC, you will *have* to master the concept of cross compiling before you can get very far.
Also, PCs are pretty limited in the different types of peripheral hardware available, and the ways by which you control them. Writing a Linux interrupt handler is not all that much different from writing a Linux application--- at least by comparison to writing an interrupt handler for a bare-metal embedded setup.
So yes, a PC isn't a bad place to start. But don't stay there long.
I'm an embedded development and training consultant. I have a tutorial on my website that features the ARM Evaluator 7T board (about $250) and a complete procedure for building the arm-elf GNU toolchain and debugging a simple "hello, world!" program.
I have both onsite and public training courses available, and I'm working on an elearning site as we speak. I'm also available for just plain old embedded development tasks. See my resume.
The ARM7TDMI chip that the Evaluator 7T uses doesn't have as many peripherals as the eCog chip you mention, but it is a true 32-bit chip with a GNU-supported instruction set and debugging environment. Hard to beat that! [/shameless plug]
Which company was that? I'd like to look them up...
Break the other half of the Wintel monopoly
on
Linux PDA From China
·
· Score: 1
iPAQ uses a StrongARM chip, which is an Intel product. It's such a buggy chip, I can't understand its success--- other than Intel's marketing muscle. Oh, and Microsoft's clout, through the PocketPC OS--- which has, conveniently, "focused" itself on the StrongARM, and left other, more appropriate chips unsupported.
And yes, I've run Linux and PocketPC/CE on StrongARM. On an iPAQ, and on a couple of other StrongARM-based devices. I've written Linux framebuffer and USB drivers for StrongARM. I know what I'm talking about here.
MIPS chips, like those found in the Agenda and this Chinese PDA (and the now discontinued Vadem Clio and others), are more cleanly designed, have less errata, and are much cheaper. Buying something that contains one of these units tells the market that you want them to select the right chip for the job, not just pick whatever Microsoft and Intel have decided to give you.
I won't buy an iPAQ, ever.
If you do, you're just giving Microsoft and Intel another sale of PocketPC+StrongARM, even if you never boot the iPAQ to anything but Linux. If you're happy with that, then you may as well run XP on your PC, too.
And don't get me started on XScale, Intel's "replacement" for the StrongARM that does even less, yet costs more. Even Microsoft admits that XScale is a real disappointment. But that's sort of like the pot calling the kettle black, isn't it?:^)
If you were writing a game based on a GPLed game, then yes, your game would have to be GPLed. If, however, you are writing a game that uses a GPLed library (like Ogre or Crystal Space) the GPL does not extend beyond the boundries of the GPLed library unless you statically link it to your code, and then distribute that statically linked binary (something no one in their right mind would do in this day and age regardless of the GPL).
Actually, wrong. Static linking vs. dynamic linking is all the same to the GPL. You still have to publish the source code for the users of the application, because according to the terms of the GPL, if you link (static, dynamic, whatever) a GPL article with your code, you have created a derivative work. And under the GPL, derivative works of GPL articles must be licensed under the GPL.
If you don't like it, write your own code. Release it under any license you like, or don't release it at all.
Re:How about an open source designed mining robot?
on
Open Source... Mining?
·
· Score: 1
The problem is that MS developers, like most, will hesitate to track down a problem that they can't duplicate, and often won't work all that hard to find the problem on their own (if they did, then the problem wouldn't exist).
Publishing the blueprints for the exploit is the only leverage the users have: "here is how you can duplicate the problem, now go fix it!".
In the short term, this feels like an unfair tactic. But over time, strongarming the vendor like this will encourage them to (a) maintain the resources to proactively fix security issues rapidly, and (b) set up an internal (or open source) peer review process to avoid the problems in the future.
In case it isn't clear, I TOTALLY support the idea of having the source code for the breach published, although perhaps after giving the vendor a few days to announce a patch. This approach is the ONLY long-term way to assure that software security gets the attention it deserves.
The reason I exclude x86 for embedded Linux experimentation is because so much stuff Just Works for x86, you can't often tell if the thing boots because you did something right, or because you got lucky.
If you are running a non-x86 setup, you have to have everything properly configured before anything useful happens. That's important when, in your "day job", you'll be running Linux on a custom SH-4 board, ARM, or whatever. From this perspective, being in command of an x86 system can be a false sense of security.
Slashdot Mirror
... like Linux's built-in features to prevent K.D. from accidentally finding sites that aren't age-appropriate, or at least haven't been pre-approved by Mom and Dad.
SCO developers and users will still have the existing and all historical versions of gcc available, and still under the GPL at that.
GCC's removal of SCO support does not violate either 5 or 6: FSF isn't proposing a SCO-specific modification to the GPL, so the LICENSE itself is not going to discriminate against SCO users or developers at all.
Besides, the GPL isn't an open source license, it's a Free Software license...
Hear hear. Having been through LFS myself several times, I'm now a diehard RH fan. There's simply too much work involved in producing a slick, fully functional Linux disto for me to want to do it myself. Not that I *can't* do it, I just prefer to leave it to someone else. Even at the full price of a boxed set, my time is still worth more than that (to me!).
:^)
Now, I agree completely that you don't know much about Linux et al until you can LFS it! I just don't want to live that way...
This is the best writing I've seen on Slashdot since.... well, ever! Bravo! :^)
Done any testing with gcc?
I think a better solution is to have two tiny dishwashers placed side by side, rather than one large one. Clean on one side, dirty on the other. :^)
Somehow, though, my wife doesn't see it that way. But now that we've got five kids (and mounds of dishes!), she may see the light.
Now, what I could *really* use is something to help with the laundry...
Surveys are exempted because they're an easy way for politicians to stay in touch with their constituents, without, um, *actually* staying in touch with their constituents. No way they're gonna legislate that convenience away!
Since when does GM do high-tech engines? :^)
Hear hear!
Care to post any links?
One more thing. You can believe the hype about GT being a top-tier school. Even in retrospect, I still believe it is. And it's an incredible bargain, too.
I checked it out, and that site sounds like a bunch of freshman whining. I was hearing those same complaints when I was there (BEE '91), all of which are highly overblown.
I lived on-campus all three years I was at GT, and rarely had problems with parking because I didn't try to drive to class (it's only like a mile between the two farthest points on campus anyway), and I did most of my commuting (grocery store, errands, etc.) during off-peak hours. I wasn't always able to park 50 ft. from my dorm, but I was always able to find a spot somewhere.
As for food, I didn't mind it. I ate at Woodruff and the SU regularly, and never had any complaints. They were no Chez Junior's (a local eatery called "Juniors" was), of course, just straight cafeteria fare. When I needed a change, I just hit one of the bazillion off-campus options.
Housing? Be realistic in your expectations, don't go expecting Club Med. It was darned convenient to live on campus, because I didn't give a shit about who my roommate was--- I was so busy with work and classes, I never saw them anyway. The dorms aren't posh, but they're far better than what GTSux makes them out to be. That includes the year I spent in Techwood, a 1940's-era (?) building that was reclaimed from a nearby housing project and turned into student housing.
Now, about academics. I'm a graduate of the engineering school, so I have limited experience in the other schools other than hearsay from fellow dorm-dwellers. But my impression is that their experiences were similar to mine. That includes the Architecture school and College of Computing.
I _never_ felt I was getting shafted, or that the profs were being unreasonable. All the professors uniformly expect you to work hard and to know how to apply the material, not just regurgitate it on a test. If you can do that, then you'll get by just fine. And you _can_ do that, if you put your mind to it. During times I was genuinely trying but struggling, the professors were very supportive.
If, on the other hand, you intend to spend your time at GT living scenes out of Animal House, you're in for trouble. The whiners behind GTSux probably fit into this category.
Just my $0.02.
I would highly recommend GT. I had my share of complaints, same as everyone else (real shortage of parking for students, for example), but overall it's a really good school and a really great experience.
:^)
Come prepared to learn! Even now, after more than ten years, I'm finding that the education I received there was more thorough and challenging than a lot of other places.
But the social life sucks. Fortunately, Emory is just down the road, and UGA isn't too far.
Why the hell do we insist on using Intel heat pumps in our laptops anyway?! There are any of a dozen different non-Intel chips that are nearly as fast as a decent P-III (or, at least, from the user's perspective) that don't need heatsinks at all! MIPS, ARM (ok, even StrongARM and XScale), SH, ...
Oh, wait, Bill doesn't want to support Windows on those chips. My bad. He'd rather force the rest of the industry and users to deal with crappy, Intel-specific problems like heat and power consumption than construct a product that's actually well-designed and portable. Yea, that's "innovative".
b.g.
I've got a cerfcube here, it's pretty nice. Their GNU toolchain setup process is kinda brain-dead, but their Linux port isn't too bad. I've heard they're moving to Familiar for their Linux setup, but I haven't taken a look lately to see what progress they've made.
Still, it *is* a StrongARM-powered device. Man, that's one buggy chip! If it didn't have Chipzilla and Micro$oft pushing it so hard, that silicon would have been made into bathroom mirrors a long time ago. Gaaak!
But yea, if you're wanting to get a quick start with embedded Linux, a 'Cube isn't a bad way to go.
Engineers fresh out of school can't handle this simple task on their own?
Nope. And I for one don't have a problem with that.
It's just a hobby for me now, but I can still slay 99% of the 'engineers' out there.
That's exactly the trouble I'm frequently called in to clean up after.
An engineering degree is mostly about training you how to think. You aren't going to learn how to write fault-tolerant code, how to harden a system to survive in an industrial environment, or anything else that's so application and domain specific. Five years just isn't long enough. And with no real practical experience to go along with them, even if you *could* train an undergraduate in those skills, you'd still be wasting your time.
The field of embedded systems is *huge*. It requires continuous effort to stay trained in the latest state of the art as it applies to solving real problems. I'll take a trainable, fresh graduate who realizes he's an idiot, over a garage hacker who thinks that since he can make a few LEDs light up on his Basic STAMP, he's ready to design a diesel engine controller.
I realize that these are sweeping generalizations on my part, ymmv.
A desktop PC is a decent place to start, but it simply can't duplicate all the concerns present in an embedded development environment.
For example, it's relatively straightforward to build a native GNU compiler, but much more difficult to build a cross-compiler (one that produces applications for a different architecture than the one the compiler ran on). Unless your embedded system is based on a PC, you will *have* to master the concept of cross compiling before you can get very far.
Also, PCs are pretty limited in the different types of peripheral hardware available, and the ways by which you control them. Writing a Linux interrupt handler is not all that much different from writing a Linux application--- at least by comparison to writing an interrupt handler for a bare-metal embedded setup.
So yes, a PC isn't a bad place to start. But don't stay there long.
[shameless plug]
I'm an embedded development and training consultant. I have a tutorial on my website that features the ARM Evaluator 7T board (about $250) and a complete procedure for building the arm-elf GNU toolchain and debugging a simple "hello, world!" program.
I have both onsite and public training courses available, and I'm working on an elearning site as we speak. I'm also available for just plain old embedded development tasks. See my resume.
The ARM7TDMI chip that the Evaluator 7T uses doesn't have as many peripherals as the eCog chip you mention, but it is a true 32-bit chip with a GNU-supported instruction set and debugging environment. Hard to beat that!
[/shameless plug]
HTH,
Which company was that? I'd like to look them up...
iPAQ uses a StrongARM chip, which is an Intel product. It's such a buggy chip, I can't understand its success--- other than Intel's marketing muscle. Oh, and Microsoft's clout, through the PocketPC OS--- which has, conveniently, "focused" itself on the StrongARM, and left other, more appropriate chips unsupported.
:^)
And yes, I've run Linux and PocketPC/CE on StrongARM. On an iPAQ, and on a couple of other StrongARM-based devices. I've written Linux framebuffer and USB drivers for StrongARM. I know what I'm talking about here.
MIPS chips, like those found in the Agenda and this Chinese PDA (and the now discontinued Vadem Clio and others), are more cleanly designed, have less errata, and are much cheaper. Buying something that contains one of these units tells the market that you want them to select the right chip for the job, not just pick whatever Microsoft and Intel have decided to give you.
I won't buy an iPAQ, ever.
If you do, you're just giving Microsoft and Intel another sale of PocketPC+StrongARM, even if you never boot the iPAQ to anything but Linux. If you're happy with that, then you may as well run XP on your PC, too.
And don't get me started on XScale, Intel's "replacement" for the StrongARM that does even less, yet costs more. Even Microsoft admits that XScale is a real disappointment. But that's sort of like the pot calling the kettle black, isn't it?
If you were writing a game based on a GPLed game, then yes, your game would have to be GPLed. If, however, you are writing a game that uses a GPLed library (like Ogre or Crystal Space) the GPL does not extend beyond the boundries of the GPLed library unless you statically link it to your code, and then distribute that statically linked binary (something no one in their right mind would do in this day and age regardless of the GPL).
Actually, wrong. Static linking vs. dynamic linking is all the same to the GPL. You still have to publish the source code for the users of the application, because according to the terms of the GPL, if you link (static, dynamic, whatever) a GPL article with your code, you have created a derivative work. And under the GPL, derivative works of GPL articles must be licensed under the GPL.
If you don't like it, write your own code. Release it under any license you like, or don't release it at all.
Hack an Aibo? :^)
The problem is that MS developers, like most, will hesitate to track down a problem that they can't duplicate, and often won't work all that hard to find the problem on their own (if they did, then the problem wouldn't exist).
Publishing the blueprints for the exploit is the only leverage the users have: "here is how you can duplicate the problem, now go fix it!".
In the short term, this feels like an unfair tactic. But over time, strongarming the vendor like this will encourage them to (a) maintain the resources to proactively fix security issues rapidly, and (b) set up an internal (or open source) peer review process to avoid the problems in the future.
In case it isn't clear, I TOTALLY support the idea of having the source code for the breach published, although perhaps after giving the vendor a few days to announce a patch. This approach is the ONLY long-term way to assure that software security gets the attention it deserves.
Just my $0.02.
The reason I exclude x86 for embedded Linux experimentation is because so much stuff Just Works for x86, you can't often tell if the thing boots because you did something right, or because you got lucky.
If you are running a non-x86 setup, you have to have everything properly configured before anything useful happens. That's important when, in your "day job", you'll be running Linux on a custom SH-4 board, ARM, or whatever. From this perspective, being in command of an x86 system can be a false sense of security.
b.g.
http://www.embedded.com
b.g.