So why doesn't linux have a pluggable scheduler, or at least allow the user to compile in SD vs. CFS at kernel compile time? Geez, this is a weird problem for Linus/linux to find himself in....
Con can always carry on by having a parallel fork of the mainline and updating that with his SD scheduler. If he feels snubbed that his code didn't make it into the mainline, well welcome to the realworld!!
Thankfully fixed now, due to Con figuring out how to satisfy both efficiency and latency objectives with a single scheduler, and Ingo rudely but efficiently pushing his own interpretation of Con's work into mainline. Moral of the story: sometimes the process is bumpy and feelings get hurt, but the code doesn't care, it just keeps getting better.
I think that's why Con is really quitting. He had the right idea in the beginning, was rejected by Ingo and the other core devs because they didn't take him seriously and then later Ingo actually submits a similar "pluggable" scheduler architecture. If I was Con, I'd be pissed too that people didn't develop at his own pace.
I suspect that if he's patient though, all of his good ideas will eventually be seen in the kernel. Patience is key though.
Um, you are right. The license on u-boot is GPLv2. What you would have to do is dump the bootloader and then extract out its method signatures to make sure it is really u-boot. It could be a clean room port of it. (although extremely doubtful...)
On a slight tangent, I was never a big fan of the Visual Studios. While XCode is definitely not perfect, it works very well. Sometimes I still miss how Emacs did things, but not having to put together a Makefile, but still have a fairly complex build process is really nice. Having a real graphics UI that works well, also really nice.
Try slickedit. It has key bindings for emacs with a more user-friendly interface and it's tagging/auto-completion is the best in the market AFAIK. I think it was modelled on the emacs way but was adapted for lesser mortals. It's less configurable then emacs but alot more usable IMHO.
Ben
PS. I feel like a marketing troll for slickedit but I just really like the software. The more recent versions have strange bugs sometimes but mostly they've kept the quality high.
You can't always kill linux applications either... sigh... Zombie processes which are waiting for IO are unkillable even with SIGKILL. However, this is getting rarer and rarer as people are learning to use select with timeout before using read/write. (honestly though, they should have read have a default timeout. If you want to read forever, use a while loop)
I use linux all of time and love it, but those are the facts AFAIK.
It is unfortunate that RMS is trying to mandate a license on a economic point. While I understand that he wants to prevent GPL'ed software from running on ALL tivo'zed devices, the DRM in this case is more of an economic barrier then a freedom to choose barrier. Tivo's economic model is to subsidize the price of the hardware by forcing it's users to buy their TV services. Should the GPL really be used to mandate economic models?
Maybe Tivo is in the wrong here by trying to use technical means to prevent people from using their devices instead of legal/contractual means. Maybe preventing tivoization is a good idea to encourage tivo to change the means it uses to discourage hardware freeloaders.
The GPL only requires that you give the source code to the people you give the binaries to. If you never release the binaries publicly, you never have to release the source code. PERIOD.
So you are an idiot with an idiot lawyer or you wrote that little piece for a certain company up in Redmond, Washington. But since you are anonymous Coward, I guess we'll never find out.
It's good to know that GNU is releasing it's newest OS to compete with Vista, MacOSX and Feisty...
Really though, I was a emacs user but since using slickedit, I haven't found emacs to be quite as satifying. I mean, I get the same key bindings and workflows as emacs but there's so much more out of the box that's usable. The tagging support and customization helper dialogs come to mind immediately.
Also, if its a simple text file I want to edit nowadays, I use kate instead. WYSIWYG is easier on the brain in these cases...
It would be great if the waste heat from powerplants (nuclear in particular) could be turned into electricity and used instead of being dumped into rivers and oceans. That's a major problem with modern nuclear plants. If a system like this could be scaled up to those systems, then baseline power generation will probably be nuclear in the future. (Assuming that breeder plants are efficient and security is tight)
I understand that you want to have total control and flexibility over the documents produced but how are you going to share them after you've made them. You can't expect a lay-user to go through a custom built XML document and understand what was written, much less the meaning and context of the communication. If you want to succeed in communicating with other people, you need to share a common media with them (aka IM, IRC, phone, ODF, doc, etc.) Thats why M$ is so desperate to maintain control of the medium of document exchange. They can charge a fortune for the tools to produce OOXML.
Thats why its important to use a more reasonable format, ODF, even if its not perfect.
I do understand the pain of WYSIWYG editors (I hate bashing doc files into shape) but if you stick to styles and occasionally add character mark-up, it's easier. At least with ODF, there is 2+ major suites supporting it and it does use the best-of-breed formats (odf, mathml, svg, musicml, png etc, all in a hierarchy in a zip file). I like it's philosophy and goals.
I think I'm beginning to see the OOXML vs. ODF conflict as a block-by-block, city-by-city, country-by-country turfwar. Each side wants it's format as the common format of editable documents.
SCMs like SVN and perforce are fundamentally different from GIT, darcs and bzr.
SVN and perforce are centralized SCMs and GIT,darcs,bzr are decentralized. So SVN,CVS,Perforce are uninteresting to Linus because he and the linux kernel developers work in a decentralized manner. Working decentralized means that there needs to be a person to receive patches from others and apply it to his tree. Anyone with write permissions can commit to a SVN server without submitting patches to a manager. Both have their own pluses and minuses.
KDE uses svn so there doesn't need to be one person to integrate all of the patches because it's a HUGE project. I guess linux is a lot smaller so Linus can handle all of the incoming changes. However, i think he mostly rubber-stamps most of the patches coming from his trusted lieutenants.
Personally, I use perforce at work. Preforce has the best GUI tools I've ever had the pleasure to use. It's also got amazing merge tools for resolving merge problems.
At home, I use svn+bzr while working on krita. svn has ok tools but bzr is amazing for transparently working as a temporary backup until i commit to the main kde svn. I find the svn cli to be good enough.
Now I have switched to XML-based formats and use XSL-FO and Apache FOP to turn it in to PDF/PostScript. I have complete control over the whole process and all of it is reusable, semantic and shareable.
So how do you specify your "XML-based format" if you don't use ODF or OOXML? Your logic for why ODF is a "lame duck open source clone" is needs more justification.
Yes, beginners should be reading articles like this but this is a couple of years out of date. Review by section: 1) Comments = Good 2) Not using magic constants is good. Using defines is BAD! Use static const instead. Then you get static type checking and when using your debugger, the value of the variable with actually appear. Even better, use a config file and a settings mechnisism so you can the game parameters without a recompile. 3) Nice sized variable names = good. Hungarian notation = BAD. Any decent modern IDE will have a "Goto declaration" function. Use it. If your IDE doesn't have that function, throw it out and quickly find out that does (kdevelop, slickedit, modern VC++, etc..) There's no reason to write obfuscated variable names because of bad technology (M$ VC 6.0) 4) Silent returns = bad! Proper error checking and handling = GOOD. In his simple case, he should be using an assert or better yet, throwing an exception. Ideally, he will properly handle the exception too. 5) this is well done, whether he quoting knuth correctly or not. 6) This is correct too. HOwever, I have to point out that he forgets to defensively add braces to some of his for loops and if statements. Unbraces control statements is asking for bugs to occur later on, especially when commenting blocks of code begins to happen. Please, please add braces around all expressions following a control statement and save a poor maintainance programmer's sanity.
I think that there was a/. post a couple of months ago pointing out that gentoo is inheritly a "bleeding-edge" distribution. You have to periodically emerge world or you'll be too out of date to catch up. At work, we only use debian because it is good enough, stable and doesn't need to be updated all of the time. However, at home it's gentoo all of the way:)
You forgot one other advantage: If an app is crashing for no appearant reason, all you have to do is specify +debug in the USE flags when emerging, debug, create patch, send patch and remove the debug flag.
Simplity itself!!
Ummm, Life on the bleeding-edge is fun... Ben
PS. A college at work recently tried installing gentoo 2007.0 and failed because of the lousy graphical installer. Made me sad:( That why I always advocate Stage1 installion using the handbook and links. Then it's a sure thing!:)
Stop/Go is the hardest on an engine and your millage efficiency.
Isn't that why hybrids are so much better in city/traffic driving then convential cars? The electric motor has 100% torque when stopped as opposed to the ICE which has 0 torque.
I'm sure there's a way for the traditional linux FS stack and ZFS to co-exist. Basically, identify the layers that are replaced by ZFS and disallow those layers to run on the same resources(volumes, drives?) that ZFS is using. Then the user has the choice of using ZFS or the normal stack.
However, I think that ZFS IS NOT the end all and be all of file systems. It's an impressive system but it alone is not worth throwing away all of the manhours put into the linux FS stack. It might warrent a fresh look at the stack though to see if there are places for refactoring available..
Thats what we did: 1) build a tool chain using http://kegel.com/crosstool/. Note: this uses glibc instead of newlib/uClibc but there are patches to make it work. 2) Download and build the mainline kernel with needed modules compiled in 3) Place onto device. 4) Develop application 5) ??? 6) Profit!
Slashdot Mirror
Agree 100%
Cheers
Ben
So why doesn't linux have a pluggable scheduler, or at least allow the user to compile in SD vs. CFS at kernel compile time?
Geez, this is a weird problem for Linus/linux to find himself in....
cheers
Ben
Con can always carry on by having a parallel fork of the mainline
and updating that with his SD scheduler. If he feels snubbed that his code didn't make it into the mainline, well welcome to the realworld!!
Cheers
Ben
Do you actually have any experience with using ext3 under windows? Is there data corruption and how is the preformance?
I'm curious because I want to have a plan for setting up a dual booting computer in the future and be able to avoid VFAT.
thanks!
Ben
Thankfully fixed now, due to Con figuring out how to satisfy both efficiency and latency objectives with a single scheduler, and Ingo rudely but efficiently pushing his own interpretation of Con's work into mainline. Moral of the story: sometimes the process is bumpy and feelings get hurt, but the code doesn't care, it just keeps getting better.
I think that's why Con is really quitting. He had the right idea in the beginning, was rejected by Ingo and the other core devs because they didn't take him seriously and then later Ingo actually submits a similar "pluggable" scheduler architecture.
If I was Con, I'd be pissed too that people didn't develop at his own pace.
I suspect that if he's patient though, all of his good ideas will eventually be seen in the kernel. Patience is key though.
Um, you are right.
The license on u-boot is GPLv2.
What you would have to do is dump the bootloader and then extract out its method signatures to make sure it is really u-boot.
It could be a clean room port of it. (although extremely doubtful...)
Cheers
BEn
Looks like a modified version of uboot.
Not surprised considering the arm chip running the iphone
Ben
On a slight tangent, I was never a big fan of the Visual Studios. While XCode is definitely not perfect, it works very well. Sometimes I still miss how Emacs did things, but not having to put together a Makefile, but still have a fairly complex build process is really nice. Having a real graphics UI that works well, also really nice.
Try slickedit. It has key bindings for emacs with a more user-friendly interface and it's tagging/auto-completion is the best in the market AFAIK. I think it was modelled on the emacs way but was adapted for lesser mortals. It's less configurable then emacs but alot more usable IMHO.
Ben
PS. I feel like a marketing troll for slickedit but I just really like the software. The more recent versions have strange bugs sometimes but mostly they've kept the quality high.
one memory profiler to profile them all: valgrind
Good but when the hell is valgrind going to run on arm?
Until then, us in embedded land are stuck with gprof. (Can oprofile even work properly on arm?)
Ben
Slickedit, enough said.
Next!
Ben
You can't always kill linux applications either... sigh...
Zombie processes which are waiting for IO are unkillable even with SIGKILL.
However, this is getting rarer and rarer as people are learning to use select with timeout before using read/write. (honestly though, they should have read have a default timeout. If you want to read forever, use a while loop)
I use linux all of time and love it, but those are the facts AFAIK.
Ben Schleimer
It is unfortunate that RMS is trying to mandate a license on a economic point. While I understand that he wants to prevent GPL'ed software from running on ALL tivo'zed devices, the DRM in this case is more of an economic barrier then a freedom to choose barrier. Tivo's economic model is to subsidize the price of the hardware by forcing it's users to buy their TV services. Should the GPL really be used to mandate economic models?
Maybe Tivo is in the wrong here by trying to use technical means to prevent people from using their devices instead of legal/contractual means. Maybe preventing tivoization is a good idea to encourage tivo to change the means it uses to discourage hardware freeloaders.
Any comments?
Ben
The GPL only requires that you give the source code to the people you give the binaries to.
If you never release the binaries publicly, you never have to release the source code. PERIOD.
So you are an idiot with an idiot lawyer or you wrote that little piece for a certain company up in Redmond, Washington. But since you are anonymous Coward, I guess we'll never find out.
It's good to know that GNU is releasing it's newest OS to compete with Vista, MacOSX and Feisty...
Really though, I was a emacs user but since using slickedit, I haven't found emacs to be quite as satifying.
I mean, I get the same key bindings and workflows as emacs but there's so much more out of the box that's usable.
The tagging support and customization helper dialogs come to mind immediately.
Also, if its a simple text file I want to edit nowadays, I use kate instead.
WYSIWYG is easier on the brain in these cases...
Cheers
Ben
Where is the heat coming from?
It would be great if the waste heat from powerplants (nuclear in particular) could be turned into electricity and used instead of being dumped into rivers and oceans. That's a major problem with modern nuclear plants. If a system like this could be scaled up to those systems, then baseline power generation will probably be nuclear in the future. (Assuming that breeder plants are efficient and security is tight)
Cheers
Ben
I understand that you want to have total control and flexibility over the documents produced but how are you going to share them after you've made them. You can't expect a lay-user to go through a custom built XML document and understand what was written, much less the meaning and context of the communication. If you want to succeed in communicating with other people, you need to share a common media with them (aka IM, IRC, phone, ODF, doc, etc.) Thats why M$ is so desperate to maintain control of the medium of document exchange. They can charge a fortune for the tools to produce OOXML.
Thats why its important to use a more reasonable format, ODF, even if its not perfect.
I do understand the pain of WYSIWYG editors (I hate bashing doc files into shape) but if you stick to styles and occasionally add character mark-up, it's easier. At least with ODF, there is 2+ major suites supporting it and it does use the best-of-breed formats (odf, mathml, svg, musicml, png etc, all in a hierarchy in a zip file). I like it's philosophy and goals.
I think I'm beginning to see the OOXML vs. ODF conflict as a block-by-block, city-by-city, country-by-country turfwar. Each side wants it's format as the common format of editable documents.
Cheers
Ben Schleimer
SCMs like SVN and perforce are fundamentally different from GIT, darcs and bzr.
SVN and perforce are centralized SCMs and GIT,darcs,bzr are decentralized.
So SVN,CVS,Perforce are uninteresting to Linus because he and the linux kernel developers work in a decentralized manner. Working decentralized means that there needs to be a person to receive patches from others and apply it to his tree. Anyone with write permissions can commit to a SVN server without submitting patches to a manager. Both have their own pluses and minuses.
KDE uses svn so there doesn't need to be one person to integrate all of the patches because it's a HUGE project. I guess linux is a lot smaller so Linus can handle all of the incoming changes. However, i think he mostly rubber-stamps most of the patches coming from his trusted lieutenants.
Personally, I use perforce at work. Preforce has the best GUI tools I've ever had the pleasure to use. It's also got amazing merge tools for resolving merge problems.
At home, I use svn+bzr while working on krita. svn has ok tools but bzr is amazing for transparently working as a temporary backup until i commit to the main kde svn. I find the svn cli to be good enough.
Cheers
Ben
Now I have switched to XML-based formats and use XSL-FO and Apache FOP to turn it in to PDF/PostScript. I have complete control over the whole process and all of it is reusable, semantic and shareable.
So how do you specify your "XML-based format" if you don't use ODF or OOXML?
Your logic for why ODF is a "lame duck open source clone" is needs more justification.
Ben
Yes, beginners should be reading articles like this but this is a couple of years out of date.
Review by section:
1) Comments = Good
2) Not using magic constants is good. Using defines is BAD! Use static const instead. Then you get static type checking and when using your debugger, the value of the variable with actually appear. Even better, use a config file and a settings mechnisism so you can the game parameters without a recompile.
3) Nice sized variable names = good. Hungarian notation = BAD. Any decent modern IDE will have a "Goto declaration" function. Use it. If your IDE doesn't have that function, throw it out and quickly find out that does (kdevelop, slickedit, modern VC++, etc..) There's no reason to write obfuscated variable names because of bad technology (M$ VC 6.0)
4) Silent returns = bad! Proper error checking and handling = GOOD. In his simple case, he should be using an assert or better yet, throwing an exception. Ideally, he will properly handle the exception too.
5) this is well done, whether he quoting knuth correctly or not.
6) This is correct too. HOwever, I have to point out that he forgets to defensively add braces to some of his for loops and if statements. Unbraces control statements is asking for bugs to occur later on, especially when commenting blocks of code begins to happen. Please, please add braces around all expressions following a control statement and save a poor maintainance programmer's sanity.
Lousy article. Gets 2 out of 5 from me.
Ben
I think that there was a /. post a couple of months ago pointing out that gentoo is inheritly a "bleeding-edge" distribution. You have to periodically emerge world or you'll be too out of date to catch up. At work, we only use debian because it is good enough, stable and doesn't need to be updated all of the time. :)
However, at home it's gentoo all of the way
Cheers
Ben
You forgot one other advantage:
:( That why I always advocate Stage1 installion using the handbook and links. :)
If an app is crashing for no appearant reason,
all you have to do is specify +debug in the USE flags when emerging, debug, create patch, send patch and remove the debug flag.
Simplity itself!!
Ummm, Life on the bleeding-edge is fun...
Ben
PS. A college at work recently tried installing gentoo 2007.0 and failed because of the lousy graphical installer. Made me sad
Then it's a sure thing!
Maybe alias rm="rm -i"
...something... ~/Trash/"
:)
or alias rm="mv -i
or tell the user just to use the bloody trash can
Ben
Stop/Go is the hardest on an engine and your millage efficiency.
Isn't that why hybrids are so much better in city/traffic driving then convential cars? The electric motor has 100% torque when stopped as opposed to the ICE which has 0 torque.
Ben
I'm sure there's a way for the traditional linux FS stack and ZFS to co-exist. Basically, identify the layers that are replaced by ZFS and disallow those layers to run on the same resources(volumes, drives?) that ZFS is using. Then the user has the choice of using ZFS or the normal stack.
However, I think that ZFS IS NOT the end all and be all of file systems. It's an impressive system but it alone is not worth throwing away all of the manhours put into the linux FS stack. It might warrent a fresh look at the stack though to see if there are places for refactoring available..
Cheers
Ben
Thats what we did:
1) build a tool chain using http://kegel.com/crosstool/. Note: this uses glibc instead of newlib/uClibc but there are patches to make it work.
2) Download and build the mainline kernel with needed modules compiled in
3) Place onto device.
4) Develop application
5) ???
6) Profit!