The most inspiring thing a manager ever said to me, and a line which I always try to use when appropriate: That's my problem, let me handle that. Clear the landmines for them and let them run.
Get online. Find a project that is vaguely interesting to you. Hack on it. Subscribe to mailing lists. Post on forums. File bugs. Read books. Write cool programs. Get some experience.
You're a punkass who has no idea what you're talking about. Mobo manufacturers have ARMIES of BIOS people.
Nobody writes a full BIOS, they all customize existing BIOSes, but don't trivialize that. A BIOS adaptation can take man-months. And don't even think about doing it without full docs.
No, it's VERY different. You have to customize the BIOS for every spin of the motherboard. The BIOS has to know how the PCI slots are wired to the PCI bridges, how the GPIO signals are run from various chips to various other chips, whether signals are pulled up or pulled down, and a lot of other very specific details.
These details change on each mobo. They change becuase the chips change, or the features change, or to make the trace routing cleaner.
These details hide proprietary details. They hide mistakes and flaws that vendors don't want you to see. They hide the fact that the 5 dollar IDE chip you have is the EXACT SAME chip as the 40 dollar RAID solution, but has a GPIO to choose the function.
Further, these details are VERY FIDDLY.
I've been writing BIOS and other x86 bootloader firmware for a few years, and it's non-trivial to get a board right, even if you do have the schematics. If you don't have the schemo, it's nigh impossible.
I was at LCA, and saw a few interesting presentations on GNOME. Here's the revelation:
THEY'RE RE-CREATING WINDOWS.
No, really, they are. That's not necessarily bad, but it is a bit scary. Look:
GConf == Registry Nautilus == Explorer shell Bonobo == DCOM GStreamer == Direct Show DBus == (something they do now)...
Much of the same duplications are being done for KDE, too. Re-inventing, re-inventing, re-inventing.
Furthermore, they're doing it worse. Or at least more slowly. Nautilus is SLOW. GNOME is much slower on equivalent hardware than Windows XP is.
I'm fine with re-implementing something that is the rigth answer. I'm not convinced all of these are, and I'm *know* we're not as fast or stable as XP in the GUI.
I want to see Linux and free/open software succeed. I really really do. I don't particularly LIKE OS/X, but it is a better experience than GNOME is, still.
I once more suggest that either the KDE team or the GNOME team concede to the other. Stop duplicating or triplicating efforts. We're still pretty far behind, and it doesn't seem to me that we're catching up (except on the simplest of desktop tasks).
The PERL mantra is CRAP. One of the desktop UI projects needs to concede, and they need to put their efforts together. KDE is good, but lacks some of what GNOME has. GNOME's recent offerings have been pretty screwed up, IMHO.
While competition is good, cannibalism isn't, and that is all the two projects do - cannibalize each other. Put the resources, people, time, brains TOGETHER. It's a hard decision to make, but they really need to do it, if either one wants to get better by the leaps and bounds we need.
The last few times I have dealt with new GNOME updates it gets WORSE AND WORSE. More bloat, more crap, less options, harder to figure out how to change things. There is nothing more frustrating that a feature you used to use all the time being taken away from you
Focus on cleanliness and efficiency. That doesn't mean that all the config options have to disappear (ahem, Metacity can bite my ass). It DOES mean that nautilus can't chew up 16 MB of memory per user just to SIT THERE.
Get it together guys, they're getting ahead of you further than you can catch up at this point.
Debugging is twice as difficult as coding. If you write the code as cleverly as you possibly can, then you are - by definition - not smart enough to debug it.
The only reason I am not 100% linux at home is music and audio software. I want to keep working on my GPLed virtual studio/sequencer, but I sure could use some help - any great C programmers out there want to pitch in - it's really waiting for a kickstart.
Yes it's hard, but the solution is pretty obvious. Actually, a multitude of solutions are obvious. As a great programmer once told me: "everything can be solved with another level of indirection".
This is the same problem that Cobalt (now Sun) solved with Sausalito (CCE, actually). You can describe the "things" in the system in abstract terms. You can describe the "actions" to occur when those "things" change (events). You can even make the register/deregister of "event"->"event handler" pretty dynamic. Now all your programs need to know about the system is the abstract "things". A bit of introspection and you have a pretty fully dynamic single interface to the system and configurable "things".
Now, I'm not saying Cobalt got it all right the first time through, but CCE is pretty cool. And it solves this age-old problem.
We had a computer (a 1U system in a manufacturer-provided shipping box - strurdy!) Be delivered once with a tire-tread across the top of the box (which was clearly computer equipment). The box was bent and mangled and pressed almost flat on one side. It looked like it had been, well, run over by a truck.
They delivered it as if nothing were wrong.
Upon opening, the sheet-metal casing was completely warped, screws had been pulled out of steel, or had their heads popped off. The Top of the case had been compressed so hard you could see the imprint of the blades of the heatsink through the sheet metal. The main-board was cracked mostly in two pieces, one disk had been squashed open the other mangled. The power-supply was a mess of cables and capacitors falling out.
They delivered it as if nothing were wrong. Needless to say, the customer wasn't too impressed and sent it back to us.
I use FruityLoops ($99 bucks, free upgrades FOREVER) on Windows for techno composition and sequencing. The sad truth is that Linux doesn't have anything like it.
So I started to write one. It's not that hard of a concept, but I realized that I was starting on a multi-year project, and I'd rather be making tunes.
Add to that the lack of anything approaching established. Linux has LADSPA for plugin FX. That's great - IF YOU LIKE MONO SOUND. Ask the LADSPA creator why there isn't stereo - the S in LADSPA is for simple. And useless.
I've got a small code-base started for a sequency with a fruityloops model. Anyone want it?
Re:On asm vs "proper" programming
on
MenuetOS Debuts
·
· Score: 5, Insightful
The point here is not whether it is "proper" to code an OS in assembly - it's been done for years. The point is that if one is to write an OS nowadays, and they choose to do it in all asm, they are doing it for the sake of doing it.
100% asm does NOT buy them improved coding efficiency or improved maintenance or debugging (I've yet to meet an asm coder who can write as much as fast as a mediocre C programmer). What 100% asm does, is make them feel special. That sounds derogatory, but it's not.
Chances are that the world doesn't need a new OS. Chances are that he didn't do anything revolutionary or groundbreaking. Chances are that he will never make a red cent off his OS. Chances are he had a great time doing it.
I've written an OS from scratch. It's hard. My OS is nothing special or groundbreaking, heck it barely DOES anything. Did I do it? yep. Did I have fun? yep. Did I learn a lot? yep. Did I do it in 100% asm? nope. I'm not that good at asm, and truth be told, I don't care THAT MUCH. I like C. C is a good language for an OS.
If this guys likes writing and debugging asm, then more power to him. But let's not mistake this for a decision about "properness" or even pure efficiency. He did it beacuse he felt like it.
Slashdot Mirror
The most inspiring thing a manager ever said to me, and a line which I always try to use when appropriate: That's my problem, let me handle that. Clear the landmines for them and let them run.
OPEN SOURCE
Get online. Find a project that is vaguely interesting to you. Hack on it. Subscribe to mailing lists. Post on forums. File bugs. Read books. Write cool programs. Get some experience.
You're a punkass who has no idea what you're talking about. Mobo manufacturers have ARMIES of BIOS people.
Nobody writes a full BIOS, they all customize existing BIOSes, but don't trivialize that. A BIOS adaptation can take man-months. And don't even think about doing it without full docs.
No, it's VERY different. You have to customize the BIOS for every spin of the motherboard. The BIOS has to know how the PCI slots are wired to the PCI bridges, how the GPIO signals are run from various chips to various other chips, whether signals are pulled up or pulled down, and a lot of other very specific details.
These details change on each mobo. They change becuase the chips change, or the features change, or to make the trace routing cleaner.
These details hide proprietary details. They hide mistakes and flaws that vendors don't want you to see. They hide the fact that the 5 dollar IDE chip you have is the EXACT SAME chip as the 40 dollar RAID solution, but has a GPIO to choose the function.
Further, these details are VERY FIDDLY.
I've been writing BIOS and other x86 bootloader firmware for a few years, and it's non-trivial to get a board right, even if you do have the schematics. If you don't have the schemo, it's nigh impossible.
How many MacOS X users just type their admin password whenever it is requested? Most of them. It's just an annoying part of running MacOS X
it's even more important to recruit people who are skilled in UI design
UI design != Human Computer Interface
HCI is *so much* more than just UI design.
I was at LCA, and saw a few interesting presentations on GNOME. Here's the revelation:
...
THEY'RE RE-CREATING WINDOWS.
No, really, they are. That's not necessarily bad, but it is a bit scary. Look:
GConf == Registry
Nautilus == Explorer shell
Bonobo == DCOM
GStreamer == Direct Show
DBus == (something they do now)
Much of the same duplications are being done for KDE, too. Re-inventing, re-inventing, re-inventing.
Furthermore, they're doing it worse. Or at least more slowly. Nautilus is SLOW. GNOME is much slower on equivalent hardware than Windows XP is.
I'm fine with re-implementing something that is the rigth answer. I'm not convinced all of these are, and I'm *know* we're not as fast or stable as XP in the GUI.
I want to see Linux and free/open software succeed. I really really do. I don't particularly LIKE OS/X, but it is a better experience than GNOME is, still.
I once more suggest that either the KDE team or the GNOME team concede to the other. Stop duplicating or triplicating efforts. We're still pretty far behind, and it doesn't seem to me that we're catching up (except on the simplest of desktop tasks).
I'd love to port up all the Cobalt stuff to 2.6 and do it properly, but free time is scarce, and Sun isn't paying for that sort of work anymore ;)
I think you left out the part about it REQUIRING a FAT partition to boot.
EFI is *fugly*. BIOS works, leave it alone. Do EFI for next-gen architectures, but for the sake of Pete, leave stuff that works alone.
We'll have 3 years of headache while vendors figure out why systems don't work with card X or OS Y.
The PERL mantra is CRAP. One of the desktop UI projects needs to concede, and they need to put their efforts together. KDE is good, but lacks some of what GNOME has. GNOME's recent offerings have been pretty screwed up, IMHO.
While competition is good, cannibalism isn't, and that is all the two projects do - cannibalize each other. Put the resources, people, time, brains TOGETHER. It's a hard decision to make, but they really need to do it, if either one wants to get better by the leaps and bounds we need.
The last few times I have dealt with new GNOME updates it gets WORSE AND WORSE. More bloat, more crap, less options, harder to figure out how to change things. There is nothing more frustrating that a feature you used to use all the time being taken away from you
Focus on cleanliness and efficiency. That doesn't mean that all the config options have to disappear (ahem, Metacity can bite my ass). It DOES mean that nautilus can't chew up 16 MB of memory per user just to SIT THERE.
Get it together guys, they're getting ahead of you further than you can catch up at this point.
Kernighan and Pike
Learn it, live it.
The only reason I am not 100% linux at home is music and audio software. I want to keep working on my GPLed virtual studio/sequencer, but I sure could use some help - any great C programmers out there want to pitch in - it's really waiting for a kickstart.
Screw Reason - Fruity Loops. http://www.fruityloops.com.
Try it for a month. Best software I ever bought. Free updates FOREVER.
Yes it's hard, but the solution is pretty obvious. Actually, a multitude of solutions are obvious. As a great programmer once told me: "everything can be solved with another level of indirection".
This is the same problem that Cobalt (now Sun) solved with Sausalito (CCE, actually). You can describe the "things" in the system in abstract terms. You can describe the "actions" to occur when those "things" change (events). You can even make the register/deregister of "event"->"event handler" pretty dynamic. Now all your programs need to know about the system is the abstract "things". A bit of introspection and you have a pretty fully dynamic single interface to the system and configurable "things".
Now, I'm not saying Cobalt got it all right the first time through, but CCE is pretty cool. And it solves this age-old problem.
The obvious answer is to write the (at least the skeleton of) the docs FIRST. Then your work is easy.
We had a computer (a 1U system in a manufacturer-provided shipping box - strurdy!) Be delivered once with a tire-tread across the top of the box (which was clearly computer equipment). The box was bent and mangled and pressed almost flat on one side. It looked like it had been, well, run over by a truck.
They delivered it as if nothing were wrong.
Upon opening, the sheet-metal casing was completely warped, screws had been pulled out of steel, or had their heads popped off. The Top of the case had been compressed so hard you could see the imprint of the blades of the heatsink through the sheet metal. The main-board was cracked mostly in two pieces, one disk had been squashed open the other mangled. The power-supply was a mess of cables and capacitors falling out.
They delivered it as if nothing were wrong. Needless to say, the customer wasn't too impressed and sent it back to us.
I use FruityLoops ($99 bucks, free upgrades FOREVER) on Windows for techno composition and sequencing. The sad truth is that Linux doesn't have anything like it.
So I started to write one. It's not that hard of a concept, but I realized that I was starting on a multi-year project, and I'd rather be making tunes.
Add to that the lack of anything approaching established. Linux has LADSPA for plugin FX. That's great - IF YOU LIKE MONO SOUND. Ask the LADSPA creator why there isn't stereo - the S in LADSPA is for simple. And useless.
I've got a small code-base started for a sequency with a fruityloops model. Anyone want it?
The point here is not whether it is "proper" to code an OS in assembly - it's been done for years. The point is that if one is to write an OS nowadays, and they choose to do it in all asm, they are doing it for the sake of doing it.
100% asm does NOT buy them improved coding efficiency or improved maintenance or debugging (I've yet to meet an asm coder who can write as much as fast as a mediocre C programmer). What 100% asm does, is make them feel special. That sounds derogatory, but it's not.
Chances are that the world doesn't need a new OS. Chances are that he didn't do anything revolutionary or groundbreaking. Chances are that he will never make a red cent off his OS. Chances are he had a great time doing it.
I've written an OS from scratch. It's hard. My OS is nothing special or groundbreaking, heck it barely DOES anything. Did I do it? yep. Did I have fun? yep. Did I learn a lot? yep. Did I do it in 100% asm? nope. I'm not that good at asm, and truth be told, I don't care THAT MUCH. I like C. C is a good language for an OS.
If this guys likes writing and debugging asm, then more power to him. But let's not mistake this for a decision about "properness" or even pure efficiency. He did it beacuse he felt like it.