Apple strives to design systems that move people towards new paradigms of work, rather than holding on to legacies.
People locked into mindsets / workflows revolving around floppy disks predicted all kinds of gloom whem Apple didn't build drives into their systems. Apple was looking ahead and asked us to go with them. The beige box builders held on to their floppies much longer because they couldn't lift their heads up and see that they were eatng grass.
Tivo, NetFlix, Phone, music, TV (cable or satellite), Internet access, paper (magazines / newspaper), ink for printers...
What is the next subscription model for a service I've gotta have? And when am I going to notice that the cumulative effect is keeping me from saving enough money for the kids college or my retirement?
I did lifetime "memberships" for Tivo Series 1 and 2. Both are still running strong. I like new gear, but I'm not constantly replacing stuff "that just works" in order to satisfy "my geek." The idea that I'll do a hardware refresh in three years so there's no diff between subscription and one time payments doesn't work for me.
At some point, there's got to be some backlash against subscription services.
I've been writing code professionally for years and now I lead others in system integration and software development.
I see new folks coming in and wasting so much time rolling their own stuff, it just kills me. The cool thing is not to build what others have already built. The cool thing is to make progress, build on what others have built, and provide users with something they can use.
Guess what guys, users don't care if your linked list code is better than anyone else's. Users want things to work. If you can spend more time concentrating on that, and less time finding and fixing the same bugs another guy dealt with two years ago, you will be doing more for users.
Guess what else. Nothing we do is perfect. That spiffy library you get from the net to solve a problem will have bugs. If you write your own, you'll have a different set of bugs.
I think too many new developers have not developed sufficient troubleshooting skills when they were learning their trade. They only know how to fix stuff they wrote because they can't get their heads around how someone else does things. I value the hardware and embedded systems work I've done because it taught me troubleshooting skills I use every day.
I can truss or trace someone elses executable binary and give the vendors / developers clues on how to fix their code without ever seeing the source code. How? Because I've developed an intuitive approach to problem solving based on the simple notion that programmers are lazy and they tend to solve similar problems in the same way. Patters are useful whether they are formal or intuitive and they are useful when developing and debugging.
When my engineers want to use a new technology in our development, I grill them very hard to determine whether they are choosing the technology just 'cause its cool and they want to learn something, or because it will actually bring some value to the product being developed. I'm all for my engineers learning new things, but I don't want them to write a lot of bad code while they figure it out. If they want to use a new technology, I prefer they re-use libs or code that an experience developer in that technology has already built. I think people should try to learn from others examples, and then innovate after achieving basic competency.
Because building good things is not limited to the likes of folks who think everything has to be re-written from scratch just becuase we have fancy new tools.
Shell scripts and their bretheren (perl, tcl/tk, python) are great glue-ware for folks who are smart enough to realize that the wheel does not need to be redesigned every few years. I can glue together existing command line tools using a few well-written lines of script to perform complex tasks that the original developers of CLI tools could not imagine.
I am thankful that CLI tool builders use stdin and stdout so that my tools can feed and be fed.
In short, people still pulling out their visual IDE tools are the people that are holding the information revoltion back. We must embrace the existing technologies and tools that make our life easier rather than waste our time building everything from scratch, simply because they are old.
Building a better Operating System
on
The End of Unix?
·
· Score: 1
Regarding the issue: We can build something better now because we know more than the dinosaurs that developed UNIX back in the pre-Cambrian era. (Issue paraphrased from various postings here)
When I was younger (and I've been writing or otherwise producing code since Jr. High, back when dinosaurs roamed the earth and Jr. High schools didn't have computers) I wanted to write or re-write everything myself. I see the younger folks who work for me now with the same attitude. Somwhere along the line I realized that the world doesn't need me to write yet another new library to operate on linked lists.
UNIX is what is it because it has evolved. Great r-wars have been fought in the halls of AT&T, Berkely, Sun Microsystems, The Linux Kernel Mailing list arguing about how things should be done. The good things survived, the cruft falls out. Evolution is a slow process, but it works. As a human, I'm thankful for the Cro-Mangum that figured out how to make a pointy stick. I'm in debt to all the ones that died because they didn't know that it was a Good Idea (TM) to get away from the sabre tooth tiger.
And now I am in debt to all those developers that have come before me, because I can build great things on top of what they have done. We don't have to go write a new OS every time some new hardware comes out anymore. We can port, port, port. Improve, improve, improve.
Starting over, "because we know better now" is a high risk proposition. If a new, primitive (primordial soup style) life form tried to take hold here on earth, it would be overwhelmed by all the advanced competition. This kind of thinking is worse than "not invented here."
I work in the defense industry in the States. I once asked several of my co-workers the following question:
Suppose the US DOD decided they needed to develop their own operating system, so they would not have to rely on Microsoft or Sun or any particular vendor. Suppose the government felt it could have better control over the features that go into an operating system if the government owned it. They could put in all the security features they wanted, they could put in classified encryption stuff right into the OS, they could preload Navy and Air Force theme music, etc.
Suppose the hired a contractor to do this. One of those really big defense contractors. The government could write up all their requirements for an operating system (A project that would take years itself) and have the contractor build it. Could such a project develop something anywhere as good as Linux, or FreeBSD, or (gosh) Windows?
I think not. Because the way the government works, they would drop a truckload (literally) of requirements, and want an OS built to meet all of those requirements all at once. They certainly wouldn't let a system evolve from simpler systems.
My rather long winded point is that UNIX, Linux, etc are successfull because they've started off small and evolved. No one can sit down and develop something as complex as the current state of Linux on one shot. Linux started off small and snowballed. So did the original AT&T UNIX.
Don't fall victim to hubris. Respect your elders. Stand on the shoulders of giants. Build up from what has come before. Wash your drapes every spring, and sweep out the dust-bunnies every fall.
Voice and natural language are great tools for communicating directly with other people. Computers are not people. Voice and natural language may not be an efficient / effective way of communicating with software elements in a computer.
10. What is the sound of one flightless wing flapping? 9. Does Tux have Buddha nature? 8. It is said that hackers who write kernel code can walk through walls ('Specially if there is pizza on the other side) 7. Following the true path means not having to come up with ten funny things if you get tired...
1. When you snatch the packet out of the firewall, you are ready to go.
It seems that Graphon has hooked itself into the Chinese market for Linux "back-office" work. I don't expect this means that the masses will have access to Linux.
[From the second link...] In recent news, GraphOn announced a strategic alliance with two technology providers in China. Through the agreement, GraphOn software will help schools in China provide Internet and network access to powerful server-based applications. GraphOn thin, server-based software will help speed adoption of Linux as China's operating system of choice while extending the usable life of their aging Windows-based PCs.
About GraphOn GraphOn develops and markets thin, server-based software to speed, centralize and simplify enterprise computing and enable efficient network deployment of applications to a wide variety of devices and platforms.
So there will be Linux servers, maby some Linux or pirated Widow's clients running browsers that can only talk to the dedicated server.
Some copies may get spread around to the greater population, but without an open netwrok in the country, it won't propagate quickly.
The reason faxes worked for them during Tienamen was because that worked in a point to point fasion.
How are they going to have a IP net in their country if there are no public ISPs? Sure, they could go back to the days of UUCP and do it like we did in the 70's, but I doubt they can pull it off without getting squashed. Their government's next step is to squash the audio bandwidth on the phone lines. Enough to let voice and low speed fax through, but not realiable enough for high speed modems. Hard to do? Don't think so Tim.
Humor has may dynamics to it. But if you really think about it, humor almost always has an element of pain to it. Do you remember Heinlein's "Stranger in a Strange Land?" Mike, the main character who was raised on Mars by the natives and doesn't have an understanding of human culture, doesn't understand humor until he goes to the zoo. While watching the monkeys, he sees one basically beat up on another, smaller monkey. The victim then proceeds to beat up on a different monkey, that one being even smaller than it is. Mike begins to laugh uncontrollably. He deduced that "people laugh because it hurts so much... because it's the only thing that'll make it stop hurting." He conjectured that when apes learn to laugh, they might be people too. That is conventional humor. It is based on pain, and is one of the ways we, as humans, deal with pain. This is not to say there is any evidence of outright humor by posting the link to the webcam. I find it more apealing to watch the storm come in using a remotely operated device, than to watch the archetypical reporter in a yellow rain slicker holding on to a tree as she reports from ground zero.
Think about it. The so-called monitoring programs they would install to snoop on us are probably all Windows based. They would be stymied on finding a Linux box.
"Hey Bill, this thing doesn't have a C: drive in it."
"Aw crap. Another Linux user. We gotta get some geek to write us a snoop program for Linux. You think AC will do it for us?"
As long as it happens in idle cycles, I really don't care what my computer is doing. I do. Any module running on my cumputer that accepts arbitrary jobs would need to have strict security and policy controls beyond "Run when idle." Such a module would have to impose security restrictions preventing hosted code from doing malicious stuff to my computer. And I will need to be able to set policies like, "Allow NOAA to run weather modeling software, but don't let Cracker Joe break passwords on this host."
As long as it happens in idle cycles, I really don't care what my computer is doing. I do. Any module running on my cumputer that accepts arbitrary jobs would need to have strict security and policy controls beyond "Run when idle." Such a module would have to impose security restrictions preventing hosted code from doing malicious stuff to my computer. And I will need to be able to set policies like, "Allow NOAA to run weather modeling software, but don't let Cracker Joe break passwords on this host."
Don't get me started on colormaps!! A couple of jobs ago, I was the only one brave enough to really dive into colormaps and understand how they worked. After that, everyone came to me. And now I shudder at all the bad code I've seen that just has no clue and does really dumb colormap management. To be fair, none of the standard O'Reily X books really cover it well. It is a dense subject, but if you are going to write image apps, you should pay a little attention to those chapters.
If you are doing things right, your colormap values shouldn't be changing out from under you. If you allocaed them, you can change them, and no other app should be bothered, because they shouldn't be using the colormap values you allocated for yourself. If you are using "shared" colormap entries, they are read-only, so they can't be changed out from under you. If you didn't bother to allocate colors, and just rummaged around the colormap looking for some pretty colors, you deserve anything that happens to you when the proper owner changes the values for those entries.
If you are talking about color flashing due to there being only one hardware colormap, its kinda pointless to try to re-dither your image, because the window manager is going to flash, all your toolkit widgets are going to flash, the whle damn display is going to look like a mess.
There is a Colormap Event anyway. Check your man pages for XColormapEvent.
I hope there's a special table reserved for X colormap guru's in heaven's 'Old X Programmer's Bar"
Slashdot Mirror
Apple strives to design systems that move people towards new paradigms of work, rather than holding on to legacies.
People locked into mindsets / workflows revolving around floppy disks predicted all kinds of gloom whem Apple didn't build drives into their systems. Apple was looking ahead and asked us to go with them. The beige box builders held on to their floppies much longer because they couldn't lift their heads up and see that they were eatng grass.
Tivo, NetFlix, Phone, music, TV (cable or satellite), Internet access, paper (magazines / newspaper), ink for printers...
What is the next subscription model for a service I've gotta have? And when am I going to notice that the cumulative effect is keeping me from saving enough money for the kids college or my retirement?
I did lifetime "memberships" for Tivo Series 1 and 2. Both are still running strong. I like new gear, but I'm not constantly replacing stuff "that just works" in order to satisfy "my geek." The idea that I'll do a hardware refresh in three years so there's no diff between subscription and one time payments doesn't work for me.
At some point, there's got to be some backlash against subscription services.
I've been writing code professionally for years and now I lead others in system integration and software development.
I see new folks coming in and wasting so much time rolling their own stuff, it just kills me. The cool thing is not to build what others have already built. The cool thing is to make progress, build on what others have built, and provide users with something they can use.
Guess what guys, users don't care if your linked list code is better than anyone else's. Users want things to work. If you can spend more time concentrating on that, and less time finding and fixing the same bugs another guy dealt with two years ago, you will be doing more for users.
Guess what else. Nothing we do is perfect. That spiffy library you get from the net to solve a problem will have bugs. If you write your own, you'll have a different set of bugs.
I think too many new developers have not developed sufficient troubleshooting skills when they were learning their trade. They only know how to fix stuff they wrote because they can't get their heads around how someone else does things. I value the hardware and embedded systems work I've done because it taught me troubleshooting skills I use every day.
I can truss or trace someone elses executable binary and give the vendors / developers clues on how to fix their code without ever seeing the source code. How? Because I've developed an intuitive approach to problem solving based on the simple notion that programmers are lazy and they tend to solve similar problems in the same way. Patters are useful whether they are formal or intuitive and they are useful when developing and debugging.
When my engineers want to use a new technology in our development, I grill them very hard to determine whether they are choosing the technology just 'cause its cool and they want to learn something, or because it will actually bring some value to the product being developed. I'm all for my engineers learning new things, but I don't want them to write a lot of bad code while they figure it out. If they want to use a new technology, I prefer they re-use libs or code that an experience developer in that technology has already built. I think people should try to learn from others examples, and then innovate after achieving basic competency.
Because building good things is not limited to the likes of folks who think everything has to be re-written from scratch just becuase we have fancy new tools.
Shell scripts and their bretheren (perl, tcl/tk, python) are great glue-ware for folks who are smart enough to realize that the wheel does not need to be redesigned every few years. I can glue together existing command line tools using a few well-written lines of script to perform complex tasks that the original developers of CLI tools could not imagine.
I am thankful that CLI tool builders use stdin and stdout so that my tools can feed and be fed.
In short, people still pulling out their visual IDE tools are the people that are holding the information revoltion back. We must embrace the existing technologies and tools that make our life easier rather than waste our time building everything from scratch, simply because they are old.
Regarding the issue:
We can build something better now because we know more than the dinosaurs that developed UNIX back in the pre-Cambrian era. (Issue paraphrased from various postings here)
When I was younger (and I've been writing or otherwise producing code since Jr. High, back when dinosaurs roamed the earth and Jr. High schools didn't have computers) I wanted to write or re-write everything myself. I see the younger folks who work for me now with the same attitude. Somwhere along the line I realized that the world doesn't need me to write yet another new library to operate on linked lists.
UNIX is what is it because it has evolved. Great r-wars have been fought in the halls of AT&T, Berkely, Sun Microsystems, The Linux Kernel Mailing list arguing about how things should be done. The good things survived, the cruft falls out. Evolution is a slow process, but it works. As a human, I'm thankful for the Cro-Mangum that figured out how to make a pointy stick. I'm in debt to all the ones that died because they didn't know that it was a Good Idea (TM) to get away from the sabre tooth tiger.
And now I am in debt to all those developers that have come before me, because I can build great things on top of what they have done. We don't have to go write a new OS every time some new hardware comes out anymore. We can port, port, port. Improve, improve, improve.
Starting over, "because we know better now" is a high risk proposition. If a new, primitive (primordial soup style) life form tried to take hold here on earth, it would be overwhelmed by all the advanced competition. This kind of thinking is worse than "not invented here."
I work in the defense industry in the States. I once asked several of my co-workers the following question:
Suppose the US DOD decided they needed to develop their own operating system, so they would not have to rely on Microsoft or Sun or any particular vendor. Suppose the government felt it could have better control over the features that go into an operating system if the government owned it. They could put in all the security features they wanted, they could put in classified encryption stuff right into the OS, they could preload Navy and Air Force theme music, etc.
Suppose the hired a contractor to do this. One of those really big defense contractors. The government could write up all their requirements for an operating system (A project that would take years itself) and have the contractor build it. Could such a project develop something anywhere as good as Linux, or FreeBSD, or (gosh) Windows?
I think not. Because the way the government works, they would drop a truckload (literally) of requirements, and want an OS built to meet all of those requirements all at once. They certainly wouldn't let a system evolve from simpler systems.
My rather long winded point is that UNIX, Linux, etc are successfull because they've started off small and evolved. No one can sit down and develop something as complex as the current state of Linux on one shot. Linux started off small and snowballed. So did the original AT&T UNIX.
Don't fall victim to hubris. Respect your elders. Stand on the shoulders of giants. Build up from what has come before. Wash your drapes every spring, and sweep out the dust-bunnies every fall.
Voice and natural language are great tools for communicating directly with other people. Computers are not people. Voice and natural language may not be an efficient / effective way of communicating with software elements in a computer.
Top ten Linux Taoist / Zen phrases.
10. What is the sound of one flightless wing flapping?
9. Does Tux have Buddha nature?
8. It is said that hackers who write kernel code can walk through walls ('Specially if there is pizza on the other side)
7. Following the true path means not having to come up with ten funny things if you get tired...
1. When you snatch the packet out of the firewall, you are ready to go.
Check this: China Wants Linux
And then this: GraphOn Corp. Reports Q3 FY99 Results
It seems that Graphon has hooked itself into the Chinese market for Linux "back-office" work. I don't expect this means that the masses will have access to Linux.
[From the second link...]
In recent news, GraphOn announced a strategic alliance with two technology providers in China. Through the agreement, GraphOn software will help schools in China provide Internet and network access to powerful server-based applications. GraphOn thin, server-based software will help speed adoption of Linux as China's operating system of choice while extending the usable life of their aging Windows-based PCs.
About GraphOn
GraphOn develops and markets thin, server-based software to speed, centralize and simplify enterprise computing and enable efficient network deployment of applications to a wide variety of devices and platforms.
So there will be Linux servers, maby some Linux or pirated Widow's clients running browsers that can only talk to the dedicated server.
Some copies may get spread around to the greater population, but without an open netwrok in the country, it won't propagate quickly.
The reason faxes worked for them during Tienamen was because that worked in a point to point fasion.
How are they going to have a IP net in their country if there are no public ISPs? Sure, they could go back to the days of UUCP and do it like we did in the 70's, but I doubt they can pull it off without getting squashed. Their government's next step is to squash the audio bandwidth on the phone lines. Enough to let voice and low speed fax through, but not realiable enough for high speed modems. Hard to do? Don't think so Tim.
Works fine for me too. Most software does in fact. Good karma. Clean living. Keep stuff in nice organized piles. Lots of ruffage. Use suntan lotion.
Humor has may dynamics to it. But if you really think about it, humor almost always has an element of pain to it.
Do you remember Heinlein's "Stranger in a Strange Land?" Mike, the main character who was raised on Mars by the natives and doesn't have an understanding of human culture, doesn't understand humor until he goes to the zoo. While watching the monkeys, he sees one basically beat up on another, smaller monkey. The victim then proceeds to beat up on a different monkey, that one being even smaller than it is. Mike begins to laugh uncontrollably. He deduced that "people laugh because it hurts so much... because it's the only thing that'll make it stop hurting." He conjectured that when apes learn to laugh, they might be people too.
That is conventional humor. It is based on pain, and is one of the ways we, as humans, deal with pain.
This is not to say there is any evidence of outright humor by posting the link to the webcam. I find it more apealing to watch the storm come in using a remotely operated device, than to watch the archetypical reporter in a yellow rain slicker holding on to a tree as she reports from ground zero.
Think about it. The so-called monitoring programs they would install to snoop on us are probably all Windows based. They would be stymied on finding a Linux box.
"Hey Bill, this thing doesn't have a C: drive in it."
"Aw crap. Another Linux user. We gotta get some geek to write us a snoop program for Linux. You think AC will do it for us?"
As long as it happens in idle cycles, I really don't care what my computer is doing.
I do. Any module running on my cumputer that accepts arbitrary jobs would need to have strict security and policy controls beyond "Run when idle." Such a module would have to impose security restrictions preventing hosted code from doing malicious stuff to my computer. And I will need to be able to set policies like, "Allow NOAA to run weather modeling software, but don't let Cracker Joe break passwords on this host."
As long as it happens in idle cycles, I really don't care what my computer is doing. I do. Any module running on my cumputer that accepts arbitrary jobs would need to have strict security and policy controls beyond "Run when idle." Such a module would have to impose security restrictions preventing hosted code from doing malicious stuff to my computer. And I will need to be able to set policies like, "Allow NOAA to run weather modeling software, but don't let Cracker Joe break passwords on this host."
Don't get me started on colormaps!! A couple of jobs ago, I was the only one brave enough to really dive into colormaps and understand how they worked. After that, everyone came to me. And now I shudder at all the bad code I've seen that just has no clue and does really dumb colormap management. To be fair, none of the standard O'Reily X books really cover it well. It is a dense subject, but if you are going to write image apps, you should pay a little attention to those chapters.
If you are doing things right, your colormap values shouldn't be changing out from under you. If you allocaed them, you can change them, and no other app should be bothered, because they shouldn't be using the colormap values you allocated for yourself. If you are using "shared" colormap entries, they are read-only, so they can't be changed out from under you. If you didn't bother to allocate colors, and just rummaged around the colormap looking for some pretty colors, you deserve anything that happens to you when the proper owner changes the values for those entries.
If you are talking about color flashing due to there being only one hardware colormap, its kinda pointless to try to re-dither your image, because the window manager is going to flash, all your toolkit widgets are going to flash, the whle damn display is going to look like a mess.
There is a Colormap Event anyway. Check your man pages for XColormapEvent.
I hope there's a special table reserved for X colormap guru's in heaven's 'Old X Programmer's Bar"
The top of the thread at Deja is at A primeval C compiler