from the article: "The end result of these studies is always the same, a grinning person telling us about how they won with open source software. Almost all of these companies say that they have cut their head count..."
I am familiar with many projects that cut staff as result of deploying easy to use/administer open source software. You'd think companies would do the opposite - hire people with the money saved - but, sadly, that's rarely the case. Just another bonus for the directors of the company. Sadly, as the article stated, very few companies ever contribute a cent towards open source. I don't see this trend ever changing.
Bruce writes: It is possible for us to make our system entirely royalty-free for solution developers, both Free and proprietary. This dictates some software choices: GNOME and PostgreSQL rather than KDE and MySQL, simply because of the way those products license proprietary developers. This will support a large ecosystem of both Free and proprietary solution developers by lowering the financial barriers to entry all the way to zero.
So, let me get this straight - he wants to discourage the use of GPL'd code in UserLinux in order to have businesses create proprietary applications that can not in turn be included into UserLinux because they will not be free?
Sounds like an interesting one-sided ecosystem.
If he took this commercial-friendly argument to its logical conclusion he would dump the GPL'd Linux from UserLinux in favour of BSD. But then it would not be much of a UserLinux, would it?
First of all, it's spelled "ridiculous". Secondly, what's the problem with paying for high quality software that saves you a lot of time and money in terms of productivity? I'm afraid that many companies are starting to equate free software with the notion that programmers are a "dime a dozen" because their work has no monetary value. Do you really think that the money saved by Linux really goes towards hiring new programmers? Ha! It goes to executives in the form of self-congratulatory bonuses for keeping costs low.
Me english not so good. Please let me correct my previous post....
Qt works equally well for applications developed on UNIX and Windows. Is the same true for GTK+? Businesses demand cross platform support for their applications. GTK+ on Windows was not up to par with GTK+ on UNIX a year ago when I tried it. Has it improved?
Qt works equally well for applications developed on UNIX and Windows. Is the same true for GTK? Businesses demand cross platform support for their applications. GTK was not up to par with UNIX a year ago when I tried it out on Windows. Has it improved?
Excuse me responding to me own post, but here's an October 2003 discussion thread on the issue of lack of (secure) multiple committer support in Arch as related to Xouvert. I did not see a simple resolution. Arch is intentionally vague on this subject seeing it as an installation/administrative issue that highlights Arch's architecural flexibility. Perhaps the Arch model just assumes a single master committer - but unfortunately most development projects I have worked on do not work that way. I see this issue chasing potential Arch users away until it is definitively resolved or adequately explained in the Arch FAQ. Does anyone know how this issue was ultimately resolved by the Xouvert project?
Specialists can only exist because of the foundation laid down by generalists. Sadly, corporations do not see this obvious truth and value people with only very narrow skillsets because they are able to assign a title to them. How many individuals can completely design, implement, test, install and manage complete end to end systems spanning desktop GUI, web, database and distributed servers these days? Not many. And the specialists will continue to drive these resourceful people out of organizations due to self-interest.
However, these same companies will soon begin to wonder why projects are not elvolving at the rapid pace they did in the "old days". They will just assume that they need to hire more specialists, and the problem cycle begins again. A top-heavy organization like this cannot be salvaged.
Do not confuse the term "generalist" with the much overhyped term "architect". An architect is a person who is simply all talk and cannot do what they say. A generalist can perform all the functions of an architect and can back up what they say with action. Generalists are the people that actually get the job done.
Antivirus software slows down your machine to a third of its original speed. Disable it and see for yourself. You'll never use that junk again.
I have a much more comprehensive scheme for identifying viruses anyway. I have modified my OS to pop a dialog for each incoming letter and verify if I want to accept it or not:
You have received the letter "G" from IP address 192.132.54.99 on port 492. Some viruses are known to have the letter "G". Would you like to accept it? Yes No
You have received the letter "r" from IP address 192.132.54.99 on port 492. Some viruses are known to have the letter "r". Would you like to accept it? Yes No
You have received the letter "e" from IP address 192.132.54.99 on port 492. Some viruses are known to have the letter "e". Would you like to accept it? Yes No
Your experience pretty much matches my experience. Writing large software systems for large companies is like pissing into an abyss. It's often a huge waste of time. Most projects fail before they even start because most high level managers/directors see reduced head counts, reduced budgets and reduced importance for themselves if the projects succeed so they do whatever they can to discredit or ruin your project.
It's fucking nuts - all the Wall Street firms are reporting RECORD PROFITS now. How do you think they are able to make those RECORD PROFITS? By using AUTOMATED SYSTEMS - that's how.
So there you have it - despite management's best efforts to bring down IT, some quality software still manages to get out and be used and ultimately makes a ton of dough for the company.
Then these same geniuses who put down IT are always the same ones that take credit for the cost efficiencies IT brings.
Perhaps the problem is you're searching for some sort of meaning in the game when it isn't there in the first place. Time to get out into the real world.
...denial is the first sign of a problem
C# generics on built-in types do not use boxing...
on
C# 2.0 Spec Released
·
· Score: 4, Interesting
From the C# 2.0 spec:
"When an instance of Stack<int> is created, the native storage of the items array is an int[] rather than object[], providing substantial storage efficiency compared to the non-generic Stack. Likewise, the Push and Pop methods of a Stack<int> operate on int values, making it a compile-time error to push values of other types onto the stack, and eliminating the need to explicitly cast values back to their original type when they're retrieved."
Java uses Object boxing for built-in types in their generics implementation.
Perhaps the problem is you're searching for some sort of meaning in the game when it isn't there in the first place. Time to get out into the real world.
CORBA failure largely due to its awful C++ API
on
Software Fashion
·
· Score: 1
Whoever designed the CORBA C++ API should be shot. No one can remember the memory management rules of this mapping. They are arbitrary and non-uniform. If someone claims they understand the C++ memory management rules they are either lieing or one of the authors of the C++ mapping. CORBA's C++ API is largely responsible for CORBA's bad reputation. Many large commercial projects threw a lot of money into this CORBA sinkhole and will never return. Perhaps other CORBA language mappings are better - they'd have a really hard time being worse!
Then there's the issue of all the unimplemented CORBA specifications, but I'll save that story for another day.
The real mark of a failed technology is when people use it in a way that it was not intended. For example, many large projects simply marshal XML strings over CORBA and avoid most of CORBA's features altogether. This way they can claim to management that they are using the company prescribed technology (CORBA) while not really using it at all. You may as well use plain sockets or HTTP if you go with this approach. CORBA provides little benefit to most projects.
That's not necessarily a bad thing - I think GCC is one of the best compilers around. The only issue here is that that particular named struct member syntax construct has been deprecated since GCC 2.5 and may be dropped in the future. If I understand the GCC docs correctly I think the alternate C99 syntax would be:
IP checksum and TCP checksum are necessary
on
HyperSCSI Examined
·
· Score: 4, Interesting
Because the IP checksum and TCP checksum occasionally disagree about the packets' validity in real-world routers and operating systems - they are both needed to provide redundancy and robustness. Stevens' TCP/IP Illustrated cites [Mogul 1992] providing counts of checksum errors on a busy NFS server:
Layer Total packets # chksum errs Ethernet 170,000,000 446 IP 170,000,000 14 UDP 140,000,000 5 TCP 30,000,000 350
Basically, when absolute accuracy is required the more error checking the better.
Qt: - most polished GUI of the bunch, great documentation, great portability, looks great. - typesafe callbacks - smallest learning curve - very easy to use. - downside: price, MOC preprocessor, very long compiles. - recommendation: if you have the money - go buy it.
FLTK: - perhaps the fastest and has the smallest memory footprint of the bunch. - small size comes with a price - the look and feel is noticably "off" and often you get non-standard widget behavior. - void* based event callbacks - fastest compiles
FOX: - programs look quite professional - non typesafe events void* pointers that are a royal pain in the butt to use, and are very poorly documented. - lack of virtual functions for most GUI classes - must use table dispatch for each new class to override behavior. - only supports UNIX (X11) and Windows - only has Windows 2000 look on any platform, but looks quite good nonetheless with minimal flicker - small user base - no CVS access - maintained by one individual
WxWindows: - supports the most platforms, has native look. - large community of support - many interpreted language bindings - different behavior on different platforms - widgets flicker like crazy - not very stable in my experience
Slashdot Mirror
Am i the only one who thinks that it would be more appropriate for /. to write it "Make more Mistaeks" ? :)
Don't be rediculous.
Don't be too hasty in dismissing this guy...
.NET Client Applications Across Windows, Linux and Unix Platforms
SourceGear, Ximian Partner on Mono Project to Deliver
from the article: "The end result of these studies is always the same, a grinning person telling us about how they won with open source software. Almost all of these companies say that they have cut their head count..."
I am familiar with many projects that cut staff as result of deploying easy to use/administer open source software. You'd think companies would do the opposite - hire people with the money saved - but, sadly, that's rarely the case. Just another bonus for the directors of the company. Sadly, as the article stated, very few companies ever contribute a cent towards open source. I don't see this trend ever changing.
Maybe if game developers could dream up a genre other than fantasy, problems like this would be averted...
How about this exciting new genre: plumbers, drywallers and electricians duke it out for world supremecy!
Bruce writes:
It is possible for us to make our system entirely royalty-free for solution developers, both Free and proprietary. This dictates some software choices: GNOME and PostgreSQL rather than KDE and MySQL, simply because of the way those products license proprietary developers. This will support a large ecosystem of both Free and proprietary solution developers by lowering the financial barriers to entry all the way to zero.
So, let me get this straight - he wants to discourage the use of GPL'd code in UserLinux in order to have businesses create proprietary applications that can not in turn be included into UserLinux because they will not be free?
Sounds like an interesting one-sided ecosystem.
If he took this commercial-friendly argument to its logical conclusion he would dump the GPL'd Linux from UserLinux in favour of BSD. But then it would not be much of a UserLinux, would it?
First of all, it's spelled "ridiculous". Secondly, what's the problem with paying for high quality software that saves you a lot of time and money in terms of productivity? I'm afraid that many companies are starting to equate free software with the notion that programmers are a "dime a dozen" because their work has no monetary value. Do you really think that the money saved by Linux really goes towards hiring new programmers? Ha! It goes to executives in the form of self-congratulatory bonuses for keeping costs low.
Me english not so good. Please let me correct my previous post....
Qt works equally well for applications developed on UNIX and Windows. Is the same true for GTK+? Businesses demand cross platform support for their applications. GTK+ on Windows was not up to par with GTK+ on UNIX a year ago when I tried it. Has it improved?
Qt works equally well for applications developed on UNIX and Windows. Is the same true for GTK? Businesses demand cross platform support for their applications. GTK was not up to par with UNIX a year ago when I tried it out on Windows. Has it improved?
Is there a way to find out who the original buyer is, or does this scheme automatically hide the buyer?
Here is the original buyer.
Excuse me responding to me own post, but here's an October 2003 discussion thread on the issue of lack of (secure) multiple committer support in Arch as related to Xouvert. I did not see a simple resolution. Arch is intentionally vague on this subject seeing it as an installation/administrative issue that highlights Arch's architecural flexibility. Perhaps the Arch model just assumes a single master committer - but unfortunately most development projects I have worked on do not work that way. I see this issue chasing potential Arch users away until it is definitively resolved or adequately explained in the Arch FAQ. Does anyone know how this issue was ultimately resolved by the Xouvert project?
I'm pleasantly surprised to see that Xouvert is using the Arch revision control system.
Does anyone know if you have to create individual UNIX user accounts for Arch users as you do with CVS? I've always hated that about CVS.
Thank you for an absolutely brilliant post.
Specialists can only exist because of the foundation laid down by generalists. Sadly, corporations do not see this obvious truth and value people with only very narrow skillsets because they are able to assign a title to them.
How many individuals can completely design, implement, test, install and manage complete end to end systems spanning desktop GUI, web, database and distributed servers these days? Not many. And the specialists will continue to drive these resourceful people out of organizations due to self-interest.
However, these same companies will soon begin to wonder why projects are not elvolving at the rapid pace they did in the "old days". They will just assume that they need to hire more specialists, and the problem cycle begins again. A top-heavy organization like this cannot be salvaged.
Do not confuse the term "generalist" with the much overhyped term "architect". An architect is a person who is simply all talk and cannot do what they say. A generalist can perform all the functions of an architect and can back up what they say with action. Generalists are the people that actually get the job done.
Antivirus software slows down your machine to a third of its original speed. Disable it and see for yourself. You'll never use that junk again.
I have a much more comprehensive scheme for identifying viruses anyway. I have modified my OS to pop a dialog for each incoming letter and verify if I want to accept it or not:
You have received the letter "G" from IP address 192.132.54.99 on port 492.
Some viruses are known to have the letter "G".
Would you like to accept it?
Yes No
You have received the letter "r" from IP address 192.132.54.99 on port 492.
Some viruses are known to have the letter "r".
Would you like to accept it?
Yes No
You have received the letter "e" from IP address 192.132.54.99 on port 492.
Some viruses are known to have the letter "e".
Would you like to accept it?
Yes No
Your experience pretty much matches my experience. Writing large software systems for large companies is like pissing into an abyss. It's often a huge waste of time. Most projects fail before they even start because most high level managers/directors see reduced head counts, reduced budgets and reduced importance for themselves if the projects succeed so they do whatever they can to discredit or ruin your project.
It's fucking nuts - all the Wall Street firms are reporting RECORD PROFITS now. How do you think they are able to make those RECORD PROFITS? By using AUTOMATED SYSTEMS - that's how.
So there you have it - despite management's best efforts to bring down IT, some quality software still manages to get out and be used and ultimately makes a ton of dough for the company.
Then these same geniuses who put down IT are always the same ones that take credit for the cost efficiencies IT brings.
Time to get out into the real world.
From the C# 2.0 spec:
"When an instance of Stack<int> is created, the native storage of the items array is an int[] rather than object[], providing substantial storage efficiency compared to the non-generic Stack. Likewise, the Push and Pop methods of a Stack<int> operate on int values, making it a compile-time error to push values of other types onto the stack, and eliminating the need to explicitly cast values back to their original type when they're retrieved."
Java uses Object boxing for built-in types in their generics implementation.
Perhaps the problem is you're searching for some sort of meaning in the game when it isn't there in the first place.
Time to get out into the real world.
Whoever designed the CORBA C++ API should be shot. No one can remember the memory management rules of this mapping. They are arbitrary and non-uniform. If someone claims they understand the C++ memory management rules they are either lieing or one of the authors of the C++ mapping. CORBA's C++ API is largely responsible for CORBA's bad reputation. Many large commercial projects threw a lot of money into this CORBA sinkhole and will never return. Perhaps other CORBA language mappings are better - they'd have a really hard time being worse!
Then there's the issue of all the unimplemented CORBA specifications, but I'll save that story for another day.
The real mark of a failed technology is when people use it in a way that it was not intended. For example, many large projects simply marshal XML strings over CORBA and avoid most of CORBA's features altogether. This way they can claim to management that they are using the company prescribed technology (CORBA) while not really using it at all. You may as well use plain sockets or HTTP if you go with this approach. CORBA provides little benefit to most projects.
This is not particularly important since Y is a work in progress, but you can see use of a GCC C extension in Y's button.c:
.c = &buttonClass, .reconfigure = buttonReconfigure, .paint = buttonPaint, .pointerButton = buttonPointerButton, .pointerMotion = buttonPointerMotion, .pointerEnter = buttonPointerEnter, .pointerLeave = buttonPointerLeave
static struct WidgetTable buttonTable =
{
c: &buttonClass,
reconfigure: buttonReconfigure,
paint: buttonPaint,
pointerButton: buttonPointerButton,
pointerMotion: buttonPointerMotion,
pointerEnter: buttonPointerEnter,
pointerLeave: buttonPointerLeave
};
That's not necessarily a bad thing - I think GCC is one of the best compilers around. The only issue here is that that particular named struct member syntax construct has been deprecated since GCC 2.5 and may be dropped in the future. If I understand the GCC docs correctly I think the alternate C99 syntax would be:
static struct WidgetTable buttonTable =
{
};
But I could be mistaken.
Because the IP checksum and TCP checksum occasionally disagree about the packets' validity in real-world routers and operating systems - they are both needed to provide redundancy and robustness. Stevens' TCP/IP Illustrated cites [Mogul 1992] providing counts of checksum errors on a busy NFS server:
Layer Total packets # chksum errs
Ethernet 170,000,000 446
IP 170,000,000 14
UDP 140,000,000 5
TCP 30,000,000 350
Basically, when absolute accuracy is required the more error checking the better.
Values taken from the ICFP 2002 webpage and munged with an awk script... not 100% accurate, but close enough.
language entries
java 28
c 24
c++ 22
caml 19
python 15
perl 11
scheme 7
haskell 6
lisp 5
dylan 2
erlang 2
mercury 2
pltbot 2
ruby 2
ada 1
bot! 1
dogs 1
extensions 1
forth 1
icon 1
kylix 1
lspm 1
mhotas 1
pandemonium 1
pps 1
prolog 1
sk 1
smalltalk 1
sml 1
v202 1
Some languages are bogus because of the format of the author's entry, or they used multiple languages.
Michael Jackson is suing the World Wildlife Federation for the right to some magical apples?
But their plot to take over the world will ultimately be foiled by Jean Luc Picard.... errr..., wrong show, but you get the idea.
And another thing - where's the radiant electricity that they promised to beam from towers in 1900? Transmission lines and power cords - blech.
It's IMPOSSIBLE to beat.
I think the key to winning has something to do with the center square, but I'm not sure.
Perhaps we'll never know.
Qt:
- most polished GUI of the bunch, great documentation, great portability, looks great.
- typesafe callbacks
- smallest learning curve - very easy to use.
- downside: price, MOC preprocessor, very long compiles.
- recommendation: if you have the money - go buy it.
FLTK:
- perhaps the fastest and has the smallest memory footprint of the bunch.
- small size comes with a price - the look and feel is noticably "off" and often you get non-standard widget behavior.
- void* based event callbacks
- fastest compiles
FOX:
- programs look quite professional
- non typesafe events void* pointers that are a royal pain in the butt to use, and are very poorly documented.
- lack of virtual functions for most GUI classes - must use table dispatch for each new class to override behavior.
- only supports UNIX (X11) and Windows
- only has Windows 2000 look on any platform, but looks quite good nonetheless with minimal flicker
- small user base
- no CVS access - maintained by one individual
WxWindows:
- supports the most platforms, has native look.
- large community of support
- many interpreted language bindings
- different behavior on different platforms
- widgets flicker like crazy
- not very stable in my experience