Actually, techs (and everyone else) is anti-management, because they realize that by and large, they understand management but management does not understand them. Most any responsible worker could be an effective manager. But most managers could not (or would not) do any other job. Your manager may be different. But they're an exception. Congratulations. Management is a game of politics and connections and favoritism.
Many techies (or line workers or burger flippers) have better understanding of the market, the customers, the competition, and the company than both their immediate supervisor and their CEO.
Many techs can speak management but choose not to. Most managers can't speak tech.
No way. Corporations want security. People work for corporations because they want security. The act of incorporation itself is a way to minimize risk. Risk takers start their own companies or work for companies that aren't necessarily stable or secure but might have potential at the cost of greater risk.
They are both wildly successful in their own target markets. Perhaps not profitable, not yet, but SuSE has a strong brand in Europe and Connectiva likewise in Latin America. Caldera and Turbo Linux offer them nothing. SuSE, at least, has a much larger base than Caldera in the U.S.A. anyway.
I predict the PR flack is enough to make United Linux crumble within the next couple weeks.
First of all, you can't use YAST2, their installer, so you'll have to write your own. Then you'll have to figure out all the dependencies. Some of them may not be open source. It'd be quicker to start from scratch.
That's exactly what they should want. 500 identical bug reports shows what the worst bug is. I've submitted a couple mozilla bugs that were duplicates recently and received good feedback. It helps to remind them too.
Granted, it'd be better to add a note to the original bug, but their bugzilla isn't exactly the most organized DB (probably largely because there are so many amateur bug reports.)
It has a plugin for Visual Studio, and allows them to create cross platform GUI apps, allowing Microsoft programs to "infiltrate" the Unix market. Show them the slot/socket event method as an example of an innovative solution created by a proprietary company, but made available to us through open source.
Despite the quickly passed buck, most of the dotcoms were conceived, build, and run by that blesses sales force of yours, not the techies. Sure, the techies got $50,000 salaries, $700 chairs, and free tshirts, which probably impressed alot of dudes who theretofore had only worked at 7-11 and hacked in their mothers' basements, but the reason they were able to surf for pr0n all day and buy cool routers they didn't need was because their ignorant bosses were all fresh out of school MBAs with family connections who changed a few words on their senior projects and got millions in VC funding.
as others have pointed out, a large part of what you want is accomplished with NNTP. For those who spend a lot of time on mailing lists, etc. this seems like an ideal solution, but really that's because what they are doing is actually using email like a newsgroup. I think you're right though about needing to be able to have the ease of retrieval that comes with IMAP and the disconnect of POP. I'm not sure of a better way to do this than NNTP (maybe that is the solution), but I think having the synched servers is a bit wasteful.
would a tarred maildir decrease the number of disk reads (renames would be trickier, but possible) and inodes, or would the tar overhead be greater than that of the filesystem?
the reason files are flat is because that is how they are stored. There is this little magnetic disk that is just a long circular line of ones and zeros. In order to read or write anything from that disk, it has to be done in sequential order (it could be parallelized, but so far that isn't practical).
So, your rich data has to be flattened out. Whether you like it or not. And at some point, whether it's the filesystem, the hardware drivers, or a chip with hardwired instructions and a cache (essentially re-implementing a large part of the os), eventually, someone is going to have to deal with that line of ones and zeros.
And that's what a filesystem does. You can obscure it, you can use links and indexes and graphical icons and properties files and block level meta-data, and hide it all from the user, but you can't take away the functionality by covering it with more layers of abstraction.
Abstraction is good. But not at the cost of functionality. I'd argue filesystems are too complex already. Look at all the tools needed already for dealing with inodes and blocks and timestanmps and so forth. That's why somes databases want to chuck it all out and start from scratch and work with the raw data.
Of course, some things, like binary tree search and journalling suffer when abstracted too far, so they're built into the filesystem. But stuffing the filesystem full of metadata isn't a compromise at all. The only thing that saves is a few file descriptors. And reieser's answer is that if files are too expensive, make them cheaper. Why not store that meta data in a separate file (or several) so that you know exactly where it is, without having to parse the every file-header for every access.
The trick to this is to make it compatible with other file systems. And that means deciding what metadata gets tossed when you convert to raw text. A file system should hold data. The more data you include in the filesystem itself, the more data you will lose in conversion. And the harder it will be to maintain and restore data. Because no file system is permanent. Think of MICRO~1.
common sense tells you to store binary files in the file system. Include a URI or path or or whatever in the DB. Believe it or not, direct file access is faster (on most OSes) than a database. You gain nothing by including a blob in the DB. It's not searchable, and it slows other searchs down. The only draw back is that you couldn't do this if you were trying to code your solution completely in SQL or for some other reason are not able access the filesystem directly.
The problem is that people don't want an alternative. They want exchange+outlook and if there is anything different (down to the icons) they won't use it. There are alternatives to Exchange. Anyone can whip up a web-based alternative to the "killer apps" of exchange, the addressbook and scheduling. But people won't use anything that doesn't work exactly the same with outlook, or that requires installation, because Dell with sell you a server with exchange already installed, and clients with outlook.
Mail clients can be built to "automatically" open a specified URL if you want to send it that way. While this might seem a potential security risk, its no more dangerous than the current featureset of some mail clients. This would reduce internet traffic (and server storage space) enormously. How many megabytes of spam are sent to every user? Alternatively, attachments could be "sent" the same way. Even using FTP (or SCP) to reduce the overhead of HTTP.
The solution isn't to re-engineer the server, but the clients.
He landed his job at Transmeta based solely on his fame from developing Linux. He might have gotten the job on his own merit, but we'll never know. As it turns out, most of his job is working on the kernel when he feels like it, and making public appearances as "creator of the free operating system GNU/Linux"
No, Linux was running into difficulties due to the lack of *any* source code control system. Linus did not like any of the other available offerings that he had tried (CVS), but agreed to give Bitkeeper a trial since Larry McVoy was a personal friend.
Even if Bitkeeper is the *best* solution out there, it is not the only thing that could overcome development difficulties. It *is* the only one that Linus is willing to try. And by now, due to the amount of time and effort expended in adapting to Bitkeeper, he's probably committed beyond any ability to change.
That is what is known as vendor lock in.
Meanwhile, Linus and others are pointing out flaws and deficiencies in Bitkeeper, while Larry moans about his "paying" customers when there are tons of eager hands to help improve his product if they were allowed to. Larry tells anyone with a suggestion that isn't Linus or a paying customer to fuck off and kiss his ass for the gift he has loudly and openly donated to the Linux kernel, which owes it's success Bitmover.com!
(remainder of whitepaper w/ pointless charts and photos deleted)
No, the practical risk is that kernel development becomes inexplicably intertwined with Bitkeeper and when Larry's accountant runs off with his wife and the company savings, Bitmover goes bankrupt and it takes a year to get development back on track.
would you support building the kernel with gcc if you had to use a proprietary product to view debug output? Sure, there's a free download of gdb, but there's no guarantee that it will still be around. Or that it will continue to work right. Oh and by the way, you can't keep using your old gcc and gdb, that's part of what you agree to to use the "free" gcc. In some countries, you could still go through the mangled debug binaries and maybe even reverse engineer a compatible debugger, but you'd be stuck playing catch up. And no one in the USA could legally use your debugger.
And then maybe, just maybe, NetBEUI has a bug in it. Too bad you can't fix it. I guess you could just send your network traffic with a different protocol, but have fun converting a network and all its idiosychrasies back to TCP/IP.
Slashdot Mirror
maintaining makefiles is probably the single hardest part of developing software
Actually, techs (and everyone else) is anti-management, because they realize that by and large, they understand management but management does not understand them. Most any responsible worker could be an effective manager. But most managers could not (or would not) do any other job. Your manager may be different. But they're an exception. Congratulations. Management is a game of politics and connections and favoritism.
Many techies (or line workers or burger flippers) have better understanding of the market, the customers, the competition, and the company than both their immediate supervisor and their CEO.
Many techs can speak management but choose not to. Most managers can't speak tech.
No way. Corporations want security. People work for corporations because they want security. The act of incorporation itself is a way to minimize risk. Risk takers start their own companies or work for companies that aren't necessarily stable or secure but might have potential at the cost of greater risk.
They are both wildly successful in their own target markets. Perhaps not profitable, not yet, but SuSE has a strong brand in Europe and Connectiva likewise in Latin America. Caldera and Turbo Linux offer them nothing. SuSE, at least, has a much larger base than Caldera in the U.S.A. anyway.
I predict the PR flack is enough to make United Linux crumble within the next couple weeks.
First of all, you can't use YAST2, their installer, so you'll have to write your own. Then you'll have to figure out all the dependencies. Some of them may not be open source. It'd be quicker to start from scratch.
That's exactly what they should want. 500 identical bug reports shows what the worst bug is. I've submitted a couple mozilla bugs that were duplicates recently and received good feedback. It helps to remind them too.
Granted, it'd be better to add a note to the original bug, but their bugzilla isn't exactly the most organized DB (probably largely because there are so many amateur bug reports.)
It has a plugin for Visual Studio, and allows them to create cross platform GUI apps, allowing Microsoft programs to "infiltrate" the Unix market. Show them the slot/socket event method as an example of an innovative solution created by a proprietary company, but made available to us through open source.
Which works fine unless ..er.. bitkeeper folds, and then the assets won't be his to release, even if he wanted to.
check out atstake.com
They used to be a bunch of kids who posted links to web defacements on attrition.org and freekevin banners.
Despite the quickly passed buck, most of the dotcoms were conceived, build, and run by that blesses sales force of yours, not the techies. Sure, the techies got $50,000 salaries, $700 chairs, and free tshirts, which probably impressed alot of dudes who theretofore had only worked at 7-11 and hacked in their mothers' basements, but the reason they were able to surf for pr0n all day and buy cool routers they didn't need was because their ignorant bosses were all fresh out of school MBAs with family connections who changed a few words on their senior projects and got millions in VC funding.
I don't know, but it's probably because there's only one phone company in Norway.
as others have pointed out, a large part of what you want is accomplished with NNTP. For those who spend a lot of time on mailing lists, etc. this seems like an ideal solution, but really that's because what they are doing is actually using email like a newsgroup. I think you're right though about needing to be able to have the ease of retrieval that comes with IMAP and the disconnect of POP. I'm not sure of a better way to do this than NNTP (maybe that is the solution), but I think having the synched servers is a bit wasteful.
I wonder...
would a tarred maildir decrease the number of disk reads (renames would be trickier, but possible) and inodes, or would the tar overhead be greater than that of the filesystem?
the reason files are flat is because that is how they are stored. There is this little magnetic disk that is just a long circular line of ones and zeros. In order to read or write anything from that disk, it has to be done in sequential order (it could be parallelized, but so far that isn't practical).
So, your rich data has to be flattened out. Whether you like it or not. And at some point, whether it's the filesystem, the hardware drivers, or a chip with hardwired instructions and a cache (essentially re-implementing a large part of the os), eventually, someone is going to have to deal with that line of ones and zeros.
And that's what a filesystem does. You can obscure it, you can use links and indexes and graphical icons and properties files and block level meta-data, and hide it all from the user, but you can't take away the functionality by covering it with more layers of abstraction.
Abstraction is good. But not at the cost of functionality. I'd argue filesystems are too complex already. Look at all the tools needed already for dealing with inodes and blocks and timestanmps and so forth. That's why somes databases want to chuck it all out and start from scratch and work with the raw data.
Of course, some things, like binary tree search and journalling suffer when abstracted too far, so they're built into the filesystem. But stuffing the filesystem full of metadata isn't a compromise at all. The only thing that saves is a few file descriptors. And reieser's answer is that if files are too expensive, make them cheaper. Why not store that meta data in a separate file (or several) so that you know exactly where it is, without having to parse the every file-header for every access.
The trick to this is to make it compatible with other file systems. And that means deciding what metadata gets tossed when you convert to raw text. A file system should hold data. The more data you include in the filesystem itself, the more data you will lose in conversion. And the harder it will be to maintain and restore data. Because no file system is permanent. Think of MICRO~1.
of course, that Dell Poweredge 2550 2x1.8ghz 4gb ram isn't used for the email. That's the admin's toy. He put the mail server on an old P100.
common sense tells you to store binary files in the file system. Include a URI or path or or whatever in the DB. Believe it or not, direct file access is faster (on most OSes) than a database. You gain nothing by including a blob in the DB. It's not searchable, and it slows other searchs down. The only draw back is that you couldn't do this if you were trying to code your solution completely in SQL or for some other reason are not able access the filesystem directly.
The problem is that people don't want an alternative. They want exchange+outlook and if there is anything different (down to the icons) they won't use it. There are alternatives to Exchange. Anyone can whip up a web-based alternative to the "killer apps" of exchange, the addressbook and scheduling. But people won't use anything that doesn't work exactly the same with outlook, or that requires installation, because Dell with sell you a server with exchange already installed, and clients with outlook.
This is the correct solution.
Mail clients can be built to "automatically" open a specified URL if you want to send it that way. While this might seem a potential security risk, its no more dangerous than the current featureset of some mail clients. This would reduce internet traffic (and server storage space) enormously. How many megabytes of spam are sent to every user? Alternatively, attachments could be "sent" the same way. Even using FTP (or SCP) to reduce the overhead of HTTP.
The solution isn't to re-engineer the server, but the clients.
I don't know how RMS feels, but if I had to choose between to two, I'd choose "modify" over "redistribute" anyday.
He landed his job at Transmeta based solely on his fame from developing Linux. He might have gotten the job on his own merit, but we'll never know. As it turns out, most of his job is working on the kernel when he feels like it, and making public appearances as "creator of the free operating system GNU/Linux"
what part of "CVS is better than mailing list archives" do you not understand?
No, Linux was running into difficulties due to the lack of *any* source code control system. Linus did not like any of the other available offerings that he had tried (CVS), but agreed to give Bitkeeper a trial since Larry McVoy was a personal friend.
Even if Bitkeeper is the *best* solution out there, it is not the only thing that could overcome development difficulties. It *is* the only one that Linus is willing to try. And by now, due to the amount of time and effort expended in adapting to Bitkeeper, he's probably committed beyond any ability to change.
That is what is known as vendor lock in.
Meanwhile, Linus and others are pointing out flaws and deficiencies in Bitkeeper, while Larry moans about his "paying" customers when there are tons of eager hands to help improve his product if they were allowed to. Larry tells anyone with a suggestion that isn't Linus or a paying customer to fuck off and kiss his ass for the gift he has loudly and openly donated to the Linux kernel, which owes it's success Bitmover.com!
(remainder of whitepaper w/ pointless charts and photos deleted)
No, the practical risk is that kernel development becomes inexplicably intertwined with Bitkeeper and when Larry's accountant runs off with his wife and the company savings, Bitmover goes bankrupt and it takes a year to get development back on track.
would you support building the kernel with gcc if you had to use a proprietary product to view debug output? Sure, there's a free download of gdb, but there's no guarantee that it will still be around. Or that it will continue to work right. Oh and by the way, you can't keep using your old gcc and gdb, that's part of what you agree to to use the "free" gcc. In some countries, you could still go through the mangled debug binaries and maybe even reverse engineer a compatible debugger, but you'd be stuck playing catch up. And no one in the USA could legally use your debugger.
And then maybe, just maybe, NetBEUI has a bug in it. Too bad you can't fix it. I guess you could just send your network traffic with a different protocol, but have fun converting a network and all its idiosychrasies back to TCP/IP.