Providing source installed would make like easier
on
Debian 3.0r4 Released
·
· Score: 1
There are lots of conflicting posts here.
Some say Debian stable is too old to be useful. Near the end
of stable's life I agree. It becomes difficult to buy hardware
Debian will run on. Upstream authors stop answering your
questions because you are running a 3 year old version they have
forgotten about.
Some say the wouldn't run anything bar stable on their servers.
I agree. After having installed Red Hat patches that broke my
production servers, it is nice to use a distribution that
knows what stable means: only bug fixes thanks.
Some say unstable is the answer to out of date software. Well
it is, but I expect a distribution to just work. Unstable
doesn't. Its fine if you just want to tinker, but if you
want to earn your bread and butter on it - well it was too
much pain for me.
Some say you can combine packages from unstable and stable.
You can - but be prepared to have most of unstable dragged in
as soon as you install something that requires a newer version
of libc. This is not a tolerable solution for servers.
The ideal solution is a mix of stable and unstable.
To make it work you have to re-compile the unstable software
on stable - this avoids the library problems (such as libc).
Mostly this just works - but sometimes it requires substantial
effort by a programmer. Either you have to put this
effort in yourself, or rely on a third party like
www.backports.org, and www.apt-get.org, or bunk2, or...
well there are so many of them you can tell it is a real
problem faced by a lot of people.
This is where allowing source installs comes in. If apt-get
allowed you to install from source, things would be easier.
In other words, apt-get install-from-source package...
downloaded, compiled, and installed just as seemlessly as
apt-get install package... does, including
downloading and install dependencies and build dependencies.
This would immediately overcome the libc problem.
Do that, and introduce a new policy. The policy says: In
order to get out of experimental and into unstable, your
package must be able to be compiled and installed via
apt-get install-from-source package... on
stable. This is not the draconian requirement is looks
like. Recall apt-get install-from-source will
download, compile and install any build dependencies as
well. So if you used cdbs and someone installed your
package on woody, cdbs would be downloaded, compiled,
and installed for the build.
Do that and volia! - you have solved maybe 80% of
the "stable is out of date" problems. Well maybe - I
assume that most people are like me don't care that a
couple of packages on their system (those from unstable)
don't get regular security patches.
If you want to move to 95+%, then that is possible too.
You have to allow multiple versions of libc (and other
libraries) to be installed side by side. This is possible
(I have have done it). Do that and I would be in distro
heaven.
If read all the posts here the "stable is too old" -
"use unstable" - "can't/won't use unstable on servers"
is the most common thread. Isn't it
worth spending some effort to fix that?
This makes IRV highly impractical as well as being technically inferior to just about every other system.
I live in Australia. We use IRV. I can assure
IRV is neither "highly impractical" nor
"technically inferior". The chances of the
anomaly you describe for IRV occurring are
statistically tiny for a large number of voters.
IRV is easy count. Condorcet is hard to
count - with a more voters than will fit in
you average class room it requires a computer.
This makes manual auditing is difficult. It
also means he IRV can be used everywhere
and Condorcet can't - it can only be used where
the necessary computing power and
telecommunication infrastructure is in place.
This is one reason why Australians uses IRV -
we were using it back when there weren't any
computers around.
As for whether Condorcet is technically
better than IRV - well that depends on whether
you prefer a 2 party system as opposed to being
governed by a coalition of minority parties.
I think the two party system isn't so bad - it
ensures whoever is elected actually gets to
govern, as opposed to spending most of their
time squabbling with the other minorities.
Since IRV does favour large parties, I prefer it
to Condorcet. As a side effect of favouring
of "centralist" parties, Condorcet gives rise
to the situation that if you have three choices, A,
B and C, with A receiving the most votes, then B,
then C, it is entirely possible C will win.
I find that odd. It happens when most of A
voters prefer C to B, and most of B voters
prefer to C to A. Condorcet chooses the
compromise, IRV forces the choice.
My company was looking some embedded hardware
with some specific capabilities. It took a while,
but last year the hardware arrived. Since I was
the first user, I was offered the choice of WinCE
or Linux. I personally prefer to develop under
Linux, but in this case I thought it was best to
go with whichever one the hardware manufacturer
was most comfortable with, and that was CE.
They supplied prototype hardware. This was
just the CPU manufacturers reference design,
which they laid up and hand soldered. A contractor
recommended by Microsoft then produced a "basic"
CE image, and we were away. So far so good.
The next step was design and delivery of
produce production boards. These were just the
reference design with unwanted bits removed, and
the form factor adjusted accordingly. Again,
they put a "basic" CE image on it, and it all
worked.
The final step was to put the "real" CE image
on the device. The major differences between
this and the basic seemed to me to be be little
details, like persisting the registry to flash,
making the CF card work, making the buttons work,
making USB work with 2.0 devices, making power
off work and so on. The job went to the same
Microsoft contractor, who promised delivery in
a week or so.
That was in January. Lots of phone calls
later, and me finally threating to cancel the
deal forced them (the manufacturer) to take
drastic steps: they made the contractor's staff
work in their offices, so they could monitor
the work being done and the progress being
made.
That was two months ago. Meanwhile the
situation was explained to Microsoft, but they
insisted the if their nominated contractor
couldn't get CE going nobody could.
More threats from me, and the manufacturer
contacted another manufacturer in Germany who
was using CE with the same reference design.
They found who did their CE image, and ask them
to do the same job.
That was a month ago. Nobody has delivered.
Nobody has raised any queries over the hardware
design. And I, an embedded programmer by trade,
and sitting here mystified by how hard it
appears to be to get CE to go.
At the same time I have written my own apps
to run on this thing. It is written in C# (which
is what Microsoft recommended). I prefer Java as
it runs well under Linux - but Microsoft does not
supply a Java VM for CE - surprise, surprise!
The back end of these apps (the server part) runs
on Linux. So I had to make C# run under Linux.
I choose PNet (as opposed to Mono) for reasons I
won't discuss here.
The contrast between the two efforts could not
be more stark. Microsoft CE.Net mostly worked
from the start, although it wasn't obvious how to
do some things and it did have one of two bugs.
Moving beyond that point - figuring out how
things work, and fixing the bugs ranged from
very hard to impossible - for all the usual
reasons. Microsoft's documentation was good,
but when it fell short there is no backup - no
source, no helpful online community, and no
one willing to fix bugs. Granted I didn't
go looking for someone looking to do these
things for money.
PNet, in contrast, didn't work well when I
first got it. It took me a day just to figure
out how to make the thing go. But progress
after that was rapid. I found bugs, I fixed
them and posted the patches. Not a lot of
doco other than the source, but if I got
stuck I asked what seems to be a thriving and
friendly online community.
It goes without saying that the PNet stuff is
now rock solid for me. The Microsoft stuff is
about where it was when we first started - very
close but no cigar, and it seems no one has any
idea how to make it progress beyond that.
I now wonder if this experience is atypical,
or if I just made the wrong choice at the
beginning. I am sure I would of have got
Linux going by now - at the cost of a lot
more effort on my part. But a little voice
inside my head keeps saying - if it is this
hard to make CE go, why does everybody keep
using it?
Bloat? Not always. The code size for J2ME is approx 64Kb. I was surprised to see that Compact.NET added 6MB to my Win CE 4.1 image. J2ME requires less than 1K of RAM on top of what your Java program uses. I haven't measured what Compact.NET uses, but its going to be 100's of times more than J2ME.
When it comes to development systems, an entire Java 1.3 development system (JBuilder8 - doco, compiler, IDE, source, etc) weighs in 680Mb. Visual Studio/progra~1/... directory weighs in at 1GB, plus whatever Microsoft see fit to scatter under the/WINNT directory. And the Borland IDE does more for you than Visual Studio, its just a nicer development environment all round.
I grant you that Swing/AWT is slow and bloated. Swing has a fatal design flaw that I don't think it will ever recover from. That is why IBM has replaced it with SWT. SWT is neither slow nor bloated.
And as for portability? Now, it is you generating FUD. Stuff written under Microsofts.NET IDE will only run under Microsoft OS's - unless you are very careful. That is effectively what story was about, really. His point was that give stuff written under Visual Studio for a Microsoft environment won't run under any of these other environments, why have them at all? You may or may not agree with his conclusion, but his premise is spot on. Java, on the other hand, is the worlds first portable language.
The article says 802.15.3a will replace BlueTooth, but
after googling around there seems to be substantial differences.
The can be summed up like this:
The figures were taken from
here and
here. The figures aren't directly compatible,
as Bluetooth takes into account the "Bluetooth protocol"
which evidently is optimised for power efficiency, whereas
I expect the in typical use your 802.15.3a will have a VB
programmer pumping TCP/IP over it. I guess that is the
payback Bluetooth gets for all that complexity.
Still, the differences are measured in orders of magnitude.
That does not meet my definition of "the same".
One of the reasons you might have trouble is that Red Hat has got this "product offering" (a lovely wanky marketing term, isn't it?) wrong. I have two major gripes with it.
Firstly: price. I have one box with 50 people running on it. At AUD$1.5K, Enterprise is priced right for that. The remainder of my boxes are "glue" that hold the network together. They do jobs like print servers, routers, firewalls and the like. They cost me AUD$300 each. What I need is a reliable Linux that has as steady supply of security patches. Red Hat plans to charge me 5 fives the cost of these machines every year for the privilege of supplying it. Obviously, that ain't going to happen.
Secondly: release schedule. 2.1AS is currently shipping with XFree86 4.1.0. So I go and buy a brand new box for AUD$500. I spare no expense - 2GHz Intel motherboard, 1/2 Gig of RAM, 40Gb HDD, Sony Floppy - nothing but the best, the most standard system I can buy. I then fork over AUD$1500 for Red Hat EA Workstation. And guess what - it won't run. XFree86 4.1.0 can't be made to support the Intel 845DV video on the motherboard.
This is actually worse than it was under the old system. If you based your systems on say Red Hat 7.0, then you had a number of years of binary compatibility (7.1, 7.2, 7.3) during which you could be sure the latest hardware was supported. And, as it happens, 7.3 does come with XFree86 4.2.0 and so it can be made to support the new Intel motherboards. But not so for its erstwhile replacement - Red Hat enterprise Linux.
I have trouble seeing now this is anything but a total marketing balls up on Red Hat's part. Yes, I can sympathise with Red Hat wanting to make money from their Linux releases. But what they had managed to do it release something that does less and cost heaps more. Before they had a single release that worked well for the hobbyist, grandma, the commercial "farm of cheap PC's" and the big iron.
Now we have:
Hobbyist desktop - well he is probably still happy. A new shiny Red Hat release every 6 months or so!
Hobbyist router - I run one of these at home. It sits in a corner for years, and untouched until the fans choke on dust. All it needs is a steady drip feed of security patches. I got the box for free - don't we all? That is about what I am prepared to pay for the OS I put on it. I am moving this one to debian.
Grandma. She got a new PC, set up by her geek grandson. All she needs is an OS that will last the lifetime of the machine (say 5 years max), which has security patches included in the purchase price for that period. This is what she gets from Microsoft for $100. She can't get it from Red Hat any more.
PC Farm. Pay several times the cost of the hardware to Red Hat in license fees every year? Get real.
Big iron running hundreds of users. Well done Red Hat. You have this 1% market niche covered!
My unwanted advice to Red Hat: try again. You can do better - far better. Currently you get nothing out of me for my "glue" boxes. Continue like this and the situation will change - for the worse. I will start installing other distributions at home, and no doubt grow to appreciate them. Or, charge me say $200 up front for a CD for an O/S with a 5 year life time, and then say $50 per year for security updates, and I will be a happy man. And I promise to never to contact you - other than to send cheques of course. The decision doesn't look too hard from where I sit.
Copyright violation in Australia is a civil offence in Australia, unless you sell the stuff. Search for the word "civil"
here.
I know this with a fair amount of certainty,
as I was on the end of a similar search warrant
during the "drink or die" bust. At the time
I was totally mystified as to why, after telling
me they were going to search my work place for
"copyright violations" and having a search
warrant that said they could look for
anything illegal under Australia law, they
took absolutely no interest in the various CD
collections we have, nor did they search any of
the workstations for illegal software.
It turned out the target was a guy who used
to work here and who did (briefly) have an IRC
chat with drink or die after it had been infiltrated. That was how they got our IP. The
cops were interested in IRC logs mainly, but I
had cleaned up the servers ages ago. His house
was later searched and the fed's did find his
collection of 200 odd pirated movies. But it
was just a hobby - he did not sell anything. I
am presuming that is why he has not been
charged.
It is a weird hobby if you ask me. It costs
more here in Australia to download & burn a
movie then it does to hire it, a lot more in
fact.
Anyway, there has to be more to this than
was reported in the article. For the police to
be involved someone must be suspected of
selling, or somehow otherwise getting monetary
gain out of illegally distributing copyrighted material. Australia's copyright laws may sound
lame from what I have said, but if someone is
found to of broken the criminal law it won't be
a slap on the wrist. They will end up in
jail.
Like everything else, POS systems are more complex than they look. The peripherals they have to support include bar code scanners, scales, magnetic card readers, touch screens, operator ID tags, customer displays, EFT devices, smart card readers, security alarms and POS printers. In more specialised areas you might attach fuel dispensers, liquor dispensers, loyalty devices, token (eg car wash) programming... the list goes on and on.
Someone made the comment about "how hard is it to drive an ASCII printer"? Well, if it just prints ASCII, perhaps not hard hard at all. But POS printers may also print logos, bar codes, cut their paper, print Credit Card signature slips, have multiple colours, warn when the paper is getting low and occasionally contain more than one print head. And no, they don't support Postscript or PCL. Usually it is some proprietary encoding scheme that is peculiar to the make and model of printer. The situation is exactly the same for the other devices for the other devices - the scanners, EFT devices, and so on. There are lots of different models. They all perform roughly the same functions, but they are all have to be driven differently.
So a few years ago Microsoft came up with OPOS, which defined a standard interface for each type of device and left it up to manufacturers to write device drivers that adhered to it. In theory we POS software writers did not worry any more about how we had to drive each device - we just wrote our POS's around the OPOS spec.
This admittedly old concept is brilliant, but in OPOS's case somewhere between the drawing board and the delivered drivers something went badly wrong. Your average driver did not work or had to be installed in some peculiar way, so you ended coding around each drivers idiosyncrasies - once you figured out what they were. Personally, I think it was easier to do it the old way. But that is irrelevant as I did not make the purchasing decision, nor did company that produced the POS software. The company buying the POS peripheral did - in this case Home Depot. And if you don't have to use it OPOS makes perfect sense - something you would include in your requirements list.
Linux does not have OPOS. In fact its worse then that, Linux has no language neutral object system that allows something like OPOS to be developed. So unless something changes drastically, Linux will never have drivers for POS peripherals that can be used by any developer, whether they use Gnome, KDE, Python, Perl, C++, or whatever. The situation could best be described as a mess. About the only out you have to to code in Java and use JavaPOS.
Speed cameras here also operate in the
same way, and have done so for years. No human
will even see your traffic fine after it leaves
the police van. The images get transferred
back to the central computer, which then
scan & enhance it, print the infringement notice
and stuff it into a envelope. I assume a human
carries it down to the post office. But it can't
be to far off before the dammed things are
delivered by email.
Scott McNeally's off the cuff comment
Privacy is dead, deal with it! is spot on.
Slashdotters may have as much trouble accepting
that as the RIAA has accepting the way
technology has gutted copyright, but the
genie is out of the bottle. You can't put it
back. No one is going to tear down the cameras
that take
300 pictures of your average Londoner
a day. No one is going to stop the hire
car companies
tracking you via satellite. Nobody is going
to stop the police tracking your movements by
asking Blockbuster when and where you last hired
out movies.
David Brin was
right. Trying to stop the collection is a
lost cause. Instead fight to make your right to
know who is collecting such information, what
they have collected, and most importantly who
has accessed it. If we can't keep their
fingers out of our packets, at least we can
keep the bastards honest!
No one has replied to this yet, so I thought I
would. Over the 20 or so years I have programmed
I have developed a methodology that is eerily
similar to yours. At the risk of repeating what
you have just said, here is how I do it:
Break the problem down into modules (aka
classes, interfaces, or whatever your favourite
silver bullet is). I don't know of any
systematic way to do this, certainly none
that guarantee a good outcome. If you have
solved similar problems before then your
design will almost certainly work well. If
not - well to quote other branches of
engineering - "plan to throw the first one
away - you will anyway".
The next step is to design the modules.
This step consists of writing the
documentation another programmer would
read to figure out how to use your new
module. The quality of what you write
should be on a par with other documentation
you think is good. For example, if you find
the Java library documentation easy to
navigate and understand, then make it look
like that.
By the way, in case it is not obvious, you
are not documenting how the module works
internally here, you are documenting its
published interfaces and how to use them.
I firmly believe the code should take
responsibility for the internal module
design.
Next, start writing the code. If you have
done the previous jobs properly your should
be able to hand your module documentation to
a team of programmers and have then work on
different modules without trampling on each
others toes. If programmer X needs to talk
to a module from programmer Y he knows what
the interface will look like, so he adds some
dummy routines that allow him to check what
is going on, and moves on.
Notice we have stopped writing pure
documentation and started writing code. But
the documentation effort has not finished.
The module programmer should be documenting
any non obvious decisions he has made with
comments.
There is one other aspect to coding the
module - it should be done defensively. The
attitude should be that the program won't fail
in my module, and just as importantly it
won't appear to fail in my module. The
latter could happen if other programmers pass
the wrong thing, or don't follow the rules and
do things in the wrong order. When that
occurs it should be obvious that is was their
mistake and not yours. The usual method is
to have your code littered with assert()'s or
their equivalent checking for the more subtle
errors that might occur. You don't have to
check for more blatant errors - like being
passed a NULL pointer for instance, because it will be
obvious that is what happened and thus is not
your fault.
The next step is unit testing. Unit
testing involves writing a test harness
which turns your module into a stand alone
program. It supplies dummy routines for all
the external modules used. Usually the
dummies just print out some trace to the test
log. And yes, if you are going to be sure
you have tested your code throughly then you
must do coverage analysis, and yes,
by far then best way I have found is the dead
tree method. Print out a listing of your
code, run a highlighter down the left hand
side when you consider a line has been tested
under all conditions. When you have a solid
line down the length of your listing you are
done. This method works a
lot better than it should. I think that is
because it forces you read your code again
with your testers hat on, and for some reason
when I do that I generally think up a lot of
devious test cases - usually along the lines
of "gee, I did not have that case in mind
when I wrote the code, I wonder if it
works?".
The unit testing code becomes a permanent
part of your modules code - it is not removed
when testing is over. I place the trace log
in there as well. That way it is easy for
someone else to re-run the test and compare
the output. If you are lucky and have
something like C's pre-processor then you
can #ifdef it, otherwise you have to manually
comment it out.
The next step is to verify all the modules
hang together the way they are supposed to.
This boils down to running the program and
testing it all works. Of course someone will
of written the user doco by now, so you can
test it against that. But as we know pigs
don't fly, so you won't have user doco yet.
Ergo you will have to test it against the
design you did in step 1. The design from
step 1 will be hopelessly out of date of
course, so you may as well start writing the
user doco.
The dead tree method still applies, but
this time to you use the module reference
documentation. You print out your module
reference doco, and put a line down the left
hand side of the page when the external
interface next to it (constant, property,
method, event, etc) when you think it has
been adequately exercised. Again, when you
have a continuous line down the left hand
side of all your doco, you are done.
If you are a one man band, ie if you
have written the program from start to
finish, then this step can be combined with
the previous one. In effect the finished
program becomes its own test harness.
Oddly enough, when I have been able to
combine the final two steps, I produce the
best code. Typically less than one defect
per 1000 loc. This is for programs of
around 15k loc (they have to be small
because I do the lot!). When I can't
combine the two steps it means there is a
team doing the work, of course, so that may
explain the difference.
The final step is beta testing. If you
are lucky you can give this job to a tester
- someone who is good at abusing the system
the way an end user might. Programmers are
not good at this - usually it is someone from
the industry the product is targeted at.
Someone who understands the damage that will
be done to their business when some part of
the product does not work, and is willing to
put in the work to ensure that doesn't
happen. I had one of these people once.
They were happy days! But very rare. The
other options are roping the public into
doing the job by publishing your program as
a "beta test", or more commonly getting the
customer to do it. If you are polite you
will warn the customer that this is a
"testing period", but telling them it is
"finished" seems to be the accepted
practice.
It is depressing, but a lot of the work you
do will be thrown away after 5 years. I get to
keep and re-use the module documentation, the
source code, and the unit tests. Having the
module documentation up to date after long period
of maintenance is unusual. It happens because I
insist it is maintained as a comment in the
source. The comment is sometimes 1000's of
lines long. In C in would like in the.h file.
At first it seems archaic having all your
documentation in 12pt courier and manually
formatted. But the programmers come to
appreciate having the documentation regardless
of what it looks like, and since it is under
their noses in a format that is easy to change
they take the time to keep it up to date. The
same applies to the unit tests and their
results.
This leaves the initial design document, the
system tests, and the beta testing as either not
re-usable or is ignored and hence just withers
and dies. You could re-use the system tests if
you had a decent test harness that recorded and
ran the tests. But in every one I have come
across is not practical. It is not hard to write
the first systems test. But as the system
evolves the effort and expertise required to
maintaining what is essentially a serial of
key strokes and mouse clicks becomes
overwhelming. It is less effort to maintain a
set of test scripts written in English and
run them manually. That is a pity, because
it seems like you could save a huge amount
of time if you could automate it.
Hmmm, I doubt anybody will read this far.
But it is nice to get your development process
down in black and white. I have not done it in
a few years, so it was time to do it again.
And it is ever so good of slashdot to keep a
permanent record of it!
Possibly they got it wrong. Or possibly its because the American billion is 10^9, and the British billion is 10^12, or at least was when I went to school. It may of changed in 20 years.
Like all good troll's there is an element of truth in what Eric says. Microsoft can not sell Windows at its current price as the price of the hardware drops. But as others here point out, the solution for Microsoft is easy: they can just drop the price of Windows accordingly. And they are likely to do just that.
But they can't keep doing it. It takes a massive investment on Microsoft's part to keep churning out each generation of Windows. So there will be a point when they can't sustain that. My guess is that point will be reached only when "Mores Law" is laid to rest - probably in 10 years or so. The price of a PC will drop dramatically then, for a number of reasons. Intel and friends won't have to put in the massive investment for each new generation of chip. We can move things onto the motherboard because next years model won't be so different. There will be less variety and hence more competition from different manufacturers producing the same thing.
When that happens the price of a PC will be a fraction of what it is now. So the price of Windows will also have to be a fraction of what it is now. Perhaps developing the operating system won't look so attractive to Microsoft then.
Many posts here argue along the lines that "people buy computer gear for entertainment, the entertainment industry will only produce stuff for gear that has DRM, ergo companies who produce DRM hardware will sell more hardware than those that don't". Well they got one bit right. It is all about money, and I don't doubt that if the hardware people thought they could make more money by selling DRM gear, they would.
But they don't think that. They think the reverse. There are several good reasons for this:
DRM enabled hardware will cost more to make.
If the DRM is broken (highly likely in the long term), non DRM gear will eat into the sales of the law abiding companies - ie the big ones who have no choice, the ones who put their name to this piece of paper.
It is more than likely that only the US will enact these laws. Asia will ignore them, and there is a backlash against this type of copy protection in Australia and Europe. This means that if the US companies want to sell overseas they will have to make both types: DRM and non DRM.
The hardware companies aren't stupid. They know which side their bread is buttered on. They will oppose DRM all the way. Not for altruistic reasons, but for the very same reasons the entertainment industry wants DRM - they will make more money without it.
I was a bit surprised to see Lessig advocating 70 years after the person's death for non-published works. He generally takes the view that things should be released into the public domain as soon as practical, because then it becomes available fresh material for other to draw upon. Yes here he is advocating withholding a letter someone writes in his 20's for say another 120 years (assuming he lives to 70).
Letters and other personal correspondence are the primary source for biographers! Surely he does not advocate the primary sources of unauthorised biographers for 120 years?
Slashdot no different to other media outlets. The editors choose the stories (no doubt from the 100's that are suggested daily) that they think will appeal to their readers. If they did not do that well Slashdot would not be here.
I am not sure how they guage how appealing a story is, but in Slashdot's case one important metric is the number of posts a story gets. Without posts the story dies. Measured like this kernel releases make pretty good news stories for Slashdot. For example when I wrote this post the stories on the front page attracted an average of 285 posts each. This one had attracted 353 posts, which is well above the average.
In other words your comment "This is not major news - this is trivial for everyone except those who are experimenting with the new kernel or developing for it" is at best irrelevant. Apparently a lot of people do think kernel announcements make interesting news, and for that reason they will continue appear on Slashdot.
She continues to propergate the myth that most artists depend on copyright to earn their money. That is crap.
Here is a thought experiment. Think of all the artists that live in your local community and who earn their living through music. Initially most people this of artists like Brittany Spears, but she isn't local. The people on you list end up like this: the piano man at the local upscale restaurant, the music teachers who teach your kids at school, the city orchestra, the performers who play at weddings, the band at the school prom, the buskers in the city mall, the national anthem singer at the local football game. Now how many of those people depend or need copyright to earn their living? Unless you live in a big city the answer will be none. If you live in a big city you may have a band or two who has hit the big time - and then the answer will be a few percent.
If it is like that in your community it is going to be like that in most communities. Ergo most musicians don't give a rats about copyright. In fact most of them would make a better living - tyey would have to fork out less royalties if there were no copyright.
Perhaps you are having trouble believing this. Try the same argument with software. Most people on slashdot will know many more programmers than they know musicans. They may develop commercial packages, they may do in house work, they may write scripts to maintain networks or web pages
Copyright only effects those that develop commercial packages, who are a small percentage of the total. But how many of those people who develop software commercial packages actually depend on copyright to protect their income? Well I work for a firm that has developed several such packages. Like most such firms we developed a software package for a particular industry. The people in the industry know nothing about software or computers, so we don't just sell the software, we install and configure it, and then supply ongoing support. For the majority of our customers the software without this service would be useless. Ergo I and my fellow programmers don't need or depend on copyright.
Now there are of course programmers who work microsoft, borland, or some such company who this does not apply to - without copyright they would be out of a job. But you know what - I personally don't know any. In fact I can't think of a single software company in the state I live in that does depend on copyright. Its a small state - just 2-3M people. Within Australia there might be a couple of hundred programmers who do depend on copyright for their jobs. A couple of hundred out of 10's of thousands.
The argument based on the "poor struggling artist" is all hand waving and bullshit. Don't be sucked in.
I would go farther than than. Microsoft sells commodity software. Commodity software is software that changes little and is used by millions of
people. In economic terms what happens to any commodity? Its price drops to the marginal cost of manufacture. For software that is the cost
of stamping the cd. So in the long term it Microsoft's current business model is going to break.
Sounds far fetched? It's not really. Even Microsoft knows it. That is why they are pushing renting software rather than selling it. With renting
they have an income stream without having to sell new software. I did not think they would succeed in renting software, until it dawned on me
that already had succeeded with Windows. Why do you think you can't resell Windows when you sell your PC? I thought it was because
Microsoft wanted get another sale of windows to the new owner. But no. It's so you can't reuse your Windows licence when you buy
yourself a new machine. Effectively you are renting Windows for the life of the PC you bought.
However renting is only a short term solution. In the longer term competitors will come out of the wood work. In 5 to 10 years KDE
Office/StarOffice/Gnome will be almost as good as Office. If it is not open source then it will be commercial in a longer time frame. But
whatever. The trigger is having your revenue stream based on selling software that does not change, that has finished evolving, that you can
no longer add features to make people upgrade. Office has reached that trigger and Windows can't be far away.
BTW, IBM is a total different kettle of fish. They sell hardware. In order to push their hardware they sell services, one of them happens to be
software. IBM will install your software, customise it for you, and run your IT department if that is what you want. Like the other 99% of
software companies in the world IBM sells a service, not a commodity. The contrast with Microsoft could not be more stark.
In order to survive in the long term Microsoft is going to have to change their business model completely. They are going to have to stop
selling software and start selling services. I don't know it they will be able to do it - it is a huge cultural change. Unlike the rabid minority on
Slashdot I think Microsoft has contributed a lot to the software engineering community. I wish them luck.
... the kind of component support Microsoft built into C#...
The original post said "KDE is still based on a lanugage with no support built in for objects", without giving a creditible alternative to C++. Then you come along and suggest C# - a language that is not available on Linux yet! Give us a break.
I am willing to bet that Microsoft produced C# as a response to Java, and more specifically Java's VM. Java's VM killed two birds with one stone - portability and security. An impressive acheivement. Notice that componentisation was not on the list. At the time Microsoft pushed ActiveX as an alternative - a component technology. It was haled as snake oil at the time. The snakes that later arose were Code Red/Nimda/SirCam/.....
This is an obviously correct and informated reply to the previous post. I guess the person who modded it down is a little wet behind the ears.
The orignal poster is correct, the primary advantage of garbage collection is run time saftey. A secondary advantage is convienence. These are two big wins. But in all other ways it looses out. It is slower, the run time of a program that uses it becomes less predictable, and because it blurs the point at which an object is destructed releasing other resources (like files) becomes problematic.
Oh, and C++ has had reflection (aka RTI) for some years. It is an add on - just like it is for Java.
I have used Word for some complex documents, and the results were not good. Things it did:
Trashed pictures, so they were cropped to the wrong size.
Stuffed up my list numbering completely.
Had my intra document references pointing to the wrong places.
In one memorable case, crashed, and in the process deleted my 120 page document. It literally disappeared - no trace of it or any of Words backup files to be found.
Don't get me wrong. Word is great at bashing out a 2 page letter, and not bad 10 page business proposal with pretty graphics and graphs. But over the decade or so I have used Word to create really large and complex documents my attitude have turned to fear and loathing. They are many packages out there (for both Windows and Linux) that are better than word for that sort of thing. I would not be surprised if StarOffice was one of them.
I remember when I first came across ASN.1 years ago. Everybody hated it because the parser was sssooo big and complex. Why not just use a simple ASCII file was a common refrain. Sure ASN.1 was capable of representing just about any data structure in a reasonably compact form, but most information did not need complex data structures to represent it so why does anybody use ASN.1?
Well a decade or two later we get the ASCII version of ASN.1 - XML. And guess what? It's arguably harder to write a generic parser for XML that it is for ASN.1. (I still have not found a good open source validating parser for XML.) But guess what - everybody is wildly enthusiastic this time round. My how times change!
Actually ASN.1 and XML in some ways are very similar. They try to solve the same problem - how to represent complex data structures in a generic way. And they do it in a similar way. Because ASN.1 is binary and uses numbers instead of text tags it does use a lot less space to represent the same thing, although 2 verus 200 bytes claim is at best misleading. Most of the 200 bytes would probably be XML header (dtd's and stuff) which you would not put in the ASN.1 encoding.
And yes, XML is too fat for some applications. For example, if you are pumping out a 60k row SQL table to your 1000 clients every day you probably would not choose XML. That is why this idea has merit. It could give you the benefits of XML without the fat. To work someone who have to come up with a standard way of translating a DTD to ASN.1 encoding. I know it's a good idea because I came up with it myself a while back:).
I am sure that if the patent really threatened to stop SAMBA development the SAMBA team would find ways around the problem. For example, they could provide an interface for an authentication "plug in" that was developed by somebody out of the reach of the patent. They could even write the plug in and make it available on a Web Site that is out of reach. Or most users could just ignore the patent. As I recall PGP has used all the of these techniques at one time or another to get around the RSA patents.
Actually the RSA / PGP example demonstrates that patents are not very effective against open source. It is far too easy to just more to the code development and distribution to a place the patent does not apply, and then rely on the users to ignore it.
Microsoft has a far more effective weapon available to it anyway - changing the protocol with every release. This has effectively nuked the NTFS driver for 'nix. It surprised me to hear that it causes SAMBA as much trouble as it does - I thought SMB would be very constrained by the existing client base. Obviously it is not constrained enough!
A number of posts here say something along the lines of "Code Red is malicious, it tried to attack the Whitehouse!". Sorry, I don't buy it. This is the type of damage a truly malicious virus does:
A malicious virus requires real effort to get rid of. At minimum you have to run a virus scanner off a clean boot. It may require a re-install. All you have to do to get rid of Code Red is reboot the machine!
A malicious virus does real damage. It formats the deletes files, formats the hard disk, or destroys the hardware by erasing the flash BIOS. Code Real attempted to deliver a DOS attack against a single IP for a couple of hours a month, and in the end even that did not work.
A malicious email virus rapidly infects all machines running any MS operating system within the organisation. It overloads the Email system (typically the most heavily used Internet App), and persists for days or weeks as people who were away at the time of the initial infection come back and read their Email. Code Red attacked 100 random IP's then stopped. It is very unlikely any of those IP's were not in your organisation, the attacks don't place that much load on the network, and they only effected NT or 2000 servers running IIS.
The thing is so benign it should be called a worm, not a virus. Anybody who things otherwise obviously has not seen the effects of a real virus attack on an organisation, or tried to clean up the consequences.
Here at work we have a lot of PC's running various versions of Windows, and a WAN network of Linux servers. The WAN covers most of Oz, so we can't visit these sites easily. The Window's machines are a PITA to support because each one is configured differently, so we looked at issuing a "Standard Operating Environment", based on Windows.
That idea was dropped fairly quickly when we realised that we would have to buy a new version of Windows for most machines, and that would cost many thousands of dollars. Actually the problem was worse than that as we have some standard apps we run on those machines, and in many cases that would have to be upgraded as well. The cost would be well in excess of $300 per machine.
Now as it happened we recently went to the some auctions to buy some machines. (Up till recently we had piles of recycled boxes lying in corners, but somehow they all used up, so it was time to buy some more.) We got some Dell 266Mhz 3Gb 64Mb boxes for AUD$300 each. More than enough to run Linux or Win9x and any office app. And there were piles of them there, all identical, more than we could ever use. We could outfit the entire organisation with these things.
It was then it hit me - the cost of just the base software, not including the office and accounting stuff, just the basic OS, virus scanners, and some Wan software, was more than the cost of the hardware. We could literally replace every office machine in the organisation with one of these things using a Linux based SOE for less that the cost of bringing the software up to a standard level on our existing hardware(!) In fact when you take into account that "older" hardware lasts 2-3 years and I would like to roll out a new "Standard Operating Environment" every year it is much cheaper.
We can't do it of course because the open source office apps aren't quite up to scratch yet. But the will be in time - roll on KOffice. Guess what I going to do then!
KFG - rarely do you see posts on slashdot that combine the humor, wit and obvious expertise that yours do here. I throughly enjoyed reading them. Well done!
Slashdot Mirror
There are lots of conflicting posts here.
Some say Debian stable is too old to be useful. Near the end of stable's life I agree. It becomes difficult to buy hardware Debian will run on. Upstream authors stop answering your questions because you are running a 3 year old version they have forgotten about.
Some say the wouldn't run anything bar stable on their servers. I agree. After having installed Red Hat patches that broke my production servers, it is nice to use a distribution that knows what stable means: only bug fixes thanks.
Some say unstable is the answer to out of date software. Well it is, but I expect a distribution to just work. Unstable doesn't. Its fine if you just want to tinker, but if you want to earn your bread and butter on it - well it was too much pain for me.
Some say you can combine packages from unstable and stable. You can - but be prepared to have most of unstable dragged in as soon as you install something that requires a newer version of libc. This is not a tolerable solution for servers.
The ideal solution is a mix of stable and unstable. To make it work you have to re-compile the unstable software on stable - this avoids the library problems (such as libc). Mostly this just works - but sometimes it requires substantial effort by a programmer. Either you have to put this effort in yourself, or rely on a third party like www.backports.org, and www.apt-get.org, or bunk2, or ...
well there are so many of them you can tell it is a real
problem faced by a lot of people.
This is where allowing source installs comes in. If apt-get allowed you to install from source, things would be easier. In other words, apt-get install-from-source package... downloaded, compiled, and installed just as seemlessly as apt-get install package... does, including downloading and install dependencies and build dependencies. This would immediately overcome the libc problem.
Do that, and introduce a new policy. The policy says: In order to get out of experimental and into unstable, your package must be able to be compiled and installed via apt-get install-from-source package... on stable. This is not the draconian requirement is looks like. Recall apt-get install-from-source will download, compile and install any build dependencies as well. So if you used cdbs and someone installed your package on woody, cdbs would be downloaded, compiled, and installed for the build.
Do that and volia! - you have solved maybe 80% of the "stable is out of date" problems. Well maybe - I assume that most people are like me don't care that a couple of packages on their system (those from unstable) don't get regular security patches.
If you want to move to 95+%, then that is possible too. You have to allow multiple versions of libc (and other libraries) to be installed side by side. This is possible (I have have done it). Do that and I would be in distro heaven.
If read all the posts here the "stable is too old" - "use unstable" - "can't/won't use unstable on servers" is the most common thread. Isn't it worth spending some effort to fix that?
I live in Australia. We use IRV. I can assure IRV is neither "highly impractical" nor "technically inferior". The chances of the anomaly you describe for IRV occurring are statistically tiny for a large number of voters.
IRV is easy count. Condorcet is hard to count - with a more voters than will fit in you average class room it requires a computer. This makes manual auditing is difficult. It also means he IRV can be used everywhere and Condorcet can't - it can only be used where the necessary computing power and telecommunication infrastructure is in place. This is one reason why Australians uses IRV - we were using it back when there weren't any computers around.
As for whether Condorcet is technically better than IRV - well that depends on whether you prefer a 2 party system as opposed to being governed by a coalition of minority parties. I think the two party system isn't so bad - it ensures whoever is elected actually gets to govern, as opposed to spending most of their time squabbling with the other minorities. Since IRV does favour large parties, I prefer it to Condorcet. As a side effect of favouring of "centralist" parties, Condorcet gives rise to the situation that if you have three choices, A, B and C, with A receiving the most votes, then B, then C, it is entirely possible C will win. I find that odd. It happens when most of A voters prefer C to B, and most of B voters prefer to C to A. Condorcet chooses the compromise, IRV forces the choice.
The ElectionMethods.org site is just a lobby group for Condorcet. Look here for a more balanced view of the various voting systems.
My company was looking some embedded hardware with some specific capabilities. It took a while, but last year the hardware arrived. Since I was the first user, I was offered the choice of WinCE or Linux. I personally prefer to develop under Linux, but in this case I thought it was best to go with whichever one the hardware manufacturer was most comfortable with, and that was CE.
They supplied prototype hardware. This was just the CPU manufacturers reference design, which they laid up and hand soldered. A contractor recommended by Microsoft then produced a "basic" CE image, and we were away. So far so good. The next step was design and delivery of produce production boards. These were just the reference design with unwanted bits removed, and the form factor adjusted accordingly. Again, they put a "basic" CE image on it, and it all worked.
The final step was to put the "real" CE image on the device. The major differences between this and the basic seemed to me to be be little details, like persisting the registry to flash, making the CF card work, making the buttons work, making USB work with 2.0 devices, making power off work and so on. The job went to the same Microsoft contractor, who promised delivery in a week or so.
That was in January. Lots of phone calls later, and me finally threating to cancel the deal forced them (the manufacturer) to take drastic steps: they made the contractor's staff work in their offices, so they could monitor the work being done and the progress being made.
That was two months ago. Meanwhile the situation was explained to Microsoft, but they insisted the if their nominated contractor couldn't get CE going nobody could.
More threats from me, and the manufacturer contacted another manufacturer in Germany who was using CE with the same reference design. They found who did their CE image, and ask them to do the same job. That was a month ago. Nobody has delivered. Nobody has raised any queries over the hardware design. And I, an embedded programmer by trade, and sitting here mystified by how hard it appears to be to get CE to go.
At the same time I have written my own apps to run on this thing. It is written in C# (which is what Microsoft recommended). I prefer Java as it runs well under Linux - but Microsoft does not supply a Java VM for CE - surprise, surprise! The back end of these apps (the server part) runs on Linux. So I had to make C# run under Linux. I choose PNet (as opposed to Mono) for reasons I won't discuss here.
The contrast between the two efforts could not be more stark. Microsoft CE.Net mostly worked from the start, although it wasn't obvious how to do some things and it did have one of two bugs. Moving beyond that point - figuring out how things work, and fixing the bugs ranged from very hard to impossible - for all the usual reasons. Microsoft's documentation was good, but when it fell short there is no backup - no source, no helpful online community, and no one willing to fix bugs. Granted I didn't go looking for someone looking to do these things for money.
PNet, in contrast, didn't work well when I first got it. It took me a day just to figure out how to make the thing go. But progress after that was rapid. I found bugs, I fixed them and posted the patches. Not a lot of doco other than the source, but if I got stuck I asked what seems to be a thriving and friendly online community.
It goes without saying that the PNet stuff is now rock solid for me. The Microsoft stuff is about where it was when we first started - very close but no cigar, and it seems no one has any idea how to make it progress beyond that.
I now wonder if this experience is atypical, or if I just made the wrong choice at the beginning. I am sure I would of have got Linux going by now - at the cost of a lot more effort on my part. But a little voice inside my head keeps saying - if it is this hard to make CE go, why does everybody keep using it?
Bloat? Not always. The code size for J2ME is approx 64Kb. I was surprised to see that Compact .NET added 6MB to my Win CE 4.1 image. J2ME requires less than 1K of RAM on top of what your Java program uses. I haven't measured what Compact .NET uses, but its going to be 100's of times more than J2ME.
When it comes to development systems, an entire Java 1.3 development system (JBuilder8 - doco, compiler, IDE, source, etc) weighs in 680Mb. Visual Studio /progra~1/... directory weighs in at 1GB, plus whatever Microsoft see fit to scatter under the /WINNT directory. And the Borland IDE does more for you than Visual Studio, its just a nicer development environment all round.
I grant you that Swing/AWT is slow and bloated. Swing has a fatal design flaw that I don't think it will ever recover from. That is why IBM has replaced it with SWT. SWT is neither slow nor bloated.
And as for portability? Now, it is you generating FUD. Stuff written under Microsofts .NET IDE will only run under Microsoft OS's - unless you are very careful. That is effectively what story was about, really. His point was that give stuff written under Visual Studio for a Microsoft environment won't run under any of these other environments, why have them at all? You may or may not agree with his conclusion, but his premise is spot on. Java, on the other hand, is the worlds first portable language.
The article says 802.15.3a will replace BlueTooth, but after googling around there seems to be substantial differences. The can be summed up like this:
. . . . . .Power. . .Speed. . .Distance .0.4Mb. . 10m..100m .100Mb. . .5m...20m
BlueTooth. . 1mW. .
802.15.3a. 200mW. .
The figures were taken from here and here. The figures aren't directly compatible, as Bluetooth takes into account the "Bluetooth protocol" which evidently is optimised for power efficiency, whereas I expect the in typical use your 802.15.3a will have a VB programmer pumping TCP/IP over it. I guess that is the payback Bluetooth gets for all that complexity.
Still, the differences are measured in orders of magnitude. That does not meet my definition of "the same".
One of the reasons you might have trouble is that Red Hat has got this "product offering" (a lovely wanky marketing term, isn't it?) wrong. I have two major gripes with it.
Firstly: price. I have one box with 50 people running on it. At AUD$1.5K, Enterprise is priced right for that. The remainder of my boxes are "glue" that hold the network together. They do jobs like print servers, routers, firewalls and the like. They cost me AUD$300 each. What I need is a reliable Linux that has as steady supply of security patches. Red Hat plans to charge me 5 fives the cost of these machines every year for the privilege of supplying it. Obviously, that ain't going to happen.
Secondly: release schedule. 2.1AS is currently shipping with XFree86 4.1.0. So I go and buy a brand new box for AUD$500. I spare no expense - 2GHz Intel motherboard, 1/2 Gig of RAM, 40Gb HDD, Sony Floppy - nothing but the best, the most standard system I can buy. I then fork over AUD$1500 for Red Hat EA Workstation. And guess what - it won't run. XFree86 4.1.0 can't be made to support the Intel 845DV video on the motherboard.
This is actually worse than it was under the old system. If you based your systems on say Red Hat 7.0, then you had a number of years of binary compatibility (7.1, 7.2, 7.3) during which you could be sure the latest hardware was supported. And, as it happens, 7.3 does come with XFree86 4.2.0 and so it can be made to support the new Intel motherboards. But not so for its erstwhile replacement - Red Hat enterprise Linux.
I have trouble seeing now this is anything but a total marketing balls up on Red Hat's part. Yes, I can sympathise with Red Hat wanting to make money from their Linux releases. But what they had managed to do it release something that does less and cost heaps more. Before they had a single release that worked well for the hobbyist, grandma, the commercial "farm of cheap PC's" and the big iron.
Now we have:
My unwanted advice to Red Hat: try again. You can do better - far better. Currently you get nothing out of me for my "glue" boxes. Continue like this and the situation will change - for the worse. I will start installing other distributions at home, and no doubt grow to appreciate them. Or, charge me say $200 up front for a CD for an O/S with a 5 year life time, and then say $50 per year for security updates, and I will be a happy man. And I promise to never to contact you - other than to send cheques of course. The decision doesn't look too hard from where I sit.
Copyright violation in Australia is a civil offence in Australia, unless you sell the stuff. Search for the word "civil" here.
I know this with a fair amount of certainty, as I was on the end of a similar search warrant during the "drink or die" bust. At the time I was totally mystified as to why, after telling me they were going to search my work place for "copyright violations" and having a search warrant that said they could look for anything illegal under Australia law, they took absolutely no interest in the various CD collections we have, nor did they search any of the workstations for illegal software.
It turned out the target was a guy who used to work here and who did (briefly) have an IRC chat with drink or die after it had been infiltrated. That was how they got our IP. The cops were interested in IRC logs mainly, but I had cleaned up the servers ages ago. His house was later searched and the fed's did find his collection of 200 odd pirated movies. But it was just a hobby - he did not sell anything. I am presuming that is why he has not been charged.
It is a weird hobby if you ask me. It costs more here in Australia to download & burn a movie then it does to hire it, a lot more in fact.
Anyway, there has to be more to this than was reported in the article. For the police to be involved someone must be suspected of selling, or somehow otherwise getting monetary gain out of illegally distributing copyrighted material. Australia's copyright laws may sound lame from what I have said, but if someone is found to of broken the criminal law it won't be a slap on the wrist. They will end up in jail.
Like everything else, POS systems are more complex than they look. The peripherals they have to support include bar code scanners, scales, magnetic card readers, touch screens, operator ID tags, customer displays, EFT devices, smart card readers, security alarms and POS printers. In more specialised areas you might attach fuel dispensers, liquor dispensers, loyalty devices, token (eg car wash) programming ... the list goes on and on.
Someone made the comment about "how hard is it to drive an ASCII printer"? Well, if it just prints ASCII, perhaps not hard hard at all. But POS printers may also print logos, bar codes, cut their paper, print Credit Card signature slips, have multiple colours, warn when the paper is getting low and occasionally contain more than one print head. And no, they don't support Postscript or PCL. Usually it is some proprietary encoding scheme that is peculiar to the make and model of printer. The situation is exactly the same for the other devices for the other devices - the scanners, EFT devices, and so on. There are lots of different models. They all perform roughly the same functions, but they are all have to be driven differently.
So a few years ago Microsoft came up with OPOS, which defined a standard interface for each type of device and left it up to manufacturers to write device drivers that adhered to it. In theory we POS software writers did not worry any more about how we had to drive each device - we just wrote our POS's around the OPOS spec.
This admittedly old concept is brilliant, but in OPOS's case somewhere between the drawing board and the delivered drivers something went badly wrong. Your average driver did not work or had to be installed in some peculiar way, so you ended coding around each drivers idiosyncrasies - once you figured out what they were. Personally, I think it was easier to do it the old way. But that is irrelevant as I did not make the purchasing decision, nor did company that produced the POS software. The company buying the POS peripheral did - in this case Home Depot. And if you don't have to use it OPOS makes perfect sense - something you would include in your requirements list.
Linux does not have OPOS. In fact its worse then that, Linux has no language neutral object system that allows something like OPOS to be developed. So unless something changes drastically, Linux will never have drivers for POS peripherals that can be used by any developer, whether they use Gnome, KDE, Python, Perl, C++, or whatever. The situation could best be described as a mess. About the only out you have to to code in Java and use JavaPOS.
This is not new. In Melbourne, Australia, a system operating on similar principles for a few years - http://www.perceptics.com/files/LPR.pdf.
Speed cameras here also operate in the same way, and have done so for years. No human will even see your traffic fine after it leaves the police van. The images get transferred back to the central computer, which then scan & enhance it, print the infringement notice and stuff it into a envelope. I assume a human carries it down to the post office. But it can't be to far off before the dammed things are delivered by email.
Scott McNeally's off the cuff comment Privacy is dead, deal with it! is spot on. Slashdotters may have as much trouble accepting that as the RIAA has accepting the way technology has gutted copyright, but the genie is out of the bottle. You can't put it back. No one is going to tear down the cameras that take 300 pictures of your average Londoner a day. No one is going to stop the hire car companies tracking you via satellite. Nobody is going to stop the police tracking your movements by asking Blockbuster when and where you last hired out movies.
David Brin was right. Trying to stop the collection is a lost cause. Instead fight to make your right to know who is collecting such information, what they have collected, and most importantly who has accessed it. If we can't keep their fingers out of our packets, at least we can keep the bastards honest!
No one has replied to this yet, so I thought I would. Over the 20 or so years I have programmed I have developed a methodology that is eerily similar to yours. At the risk of repeating what you have just said, here is how I do it:
The next step is to design the modules. This step consists of writing the documentation another programmer would read to figure out how to use your new module. The quality of what you write should be on a par with other documentation you think is good. For example, if you find the Java library documentation easy to navigate and understand, then make it look like that.
By the way, in case it is not obvious, you are not documenting how the module works internally here, you are documenting its published interfaces and how to use them. I firmly believe the code should take responsibility for the internal module design.
Next, start writing the code. If you have done the previous jobs properly your should be able to hand your module documentation to a team of programmers and have then work on different modules without trampling on each others toes. If programmer X needs to talk to a module from programmer Y he knows what the interface will look like, so he adds some dummy routines that allow him to check what is going on, and moves on.
Notice we have stopped writing pure documentation and started writing code. But the documentation effort has not finished. The module programmer should be documenting any non obvious decisions he has made with comments.
There is one other aspect to coding the module - it should be done defensively. The attitude should be that the program won't fail in my module, and just as importantly it won't appear to fail in my module. The latter could happen if other programmers pass the wrong thing, or don't follow the rules and do things in the wrong order. When that occurs it should be obvious that is was their mistake and not yours. The usual method is to have your code littered with assert()'s or their equivalent checking for the more subtle errors that might occur. You don't have to check for more blatant errors - like being passed a NULL pointer for instance, because it will be obvious that is what happened and thus is not your fault.
The next step is unit testing. Unit testing involves writing a test harness which turns your module into a stand alone program. It supplies dummy routines for all the external modules used. Usually the dummies just print out some trace to the test log. And yes, if you are going to be sure you have tested your code throughly then you must do coverage analysis, and yes, by far then best way I have found is the dead tree method. Print out a listing of your code, run a highlighter down the left hand side when you consider a line has been tested under all conditions. When you have a solid line down the length of your listing you are done. This method works a lot better than it should. I think that is because it forces you read your code again with your testers hat on, and for some reason when I do that I generally think up a lot of devious test cases - usually along the lines of "gee, I did not have that case in mind when I wrote the code, I wonder if it works?".
The unit testing code becomes a permanent part of your modules code - it is not removed when testing is over. I place the trace log in there as well. That way it is easy for someone else to re-run the test and compare the output. If you are lucky and have something like C's pre-processor then you can #ifdef it, otherwise you have to manually comment it out.
The next step is to verify all the modules hang together the way they are supposed to. This boils down to running the program and testing it all works. Of course someone will of written the user doco by now, so you can test it against that. But as we know pigs don't fly, so you won't have user doco yet. Ergo you will have to test it against the design you did in step 1. The design from step 1 will be hopelessly out of date of course, so you may as well start writing the user doco.
The dead tree method still applies, but this time to you use the module reference documentation. You print out your module reference doco, and put a line down the left hand side of the page when the external interface next to it (constant, property, method, event, etc) when you think it has been adequately exercised. Again, when you have a continuous line down the left hand side of all your doco, you are done.
If you are a one man band, ie if you have written the program from start to finish, then this step can be combined with the previous one. In effect the finished program becomes its own test harness.
Oddly enough, when I have been able to combine the final two steps, I produce the best code. Typically less than one defect per 1000 loc. This is for programs of around 15k loc (they have to be small because I do the lot!). When I can't combine the two steps it means there is a team doing the work, of course, so that may explain the difference.
The final step is beta testing. If you are lucky you can give this job to a tester - someone who is good at abusing the system the way an end user might. Programmers are not good at this - usually it is someone from the industry the product is targeted at. Someone who understands the damage that will be done to their business when some part of the product does not work, and is willing to put in the work to ensure that doesn't happen. I had one of these people once. They were happy days! But very rare. The other options are roping the public into doing the job by publishing your program as a "beta test", or more commonly getting the customer to do it. If you are polite you will warn the customer that this is a "testing period", but telling them it is "finished" seems to be the accepted practice.
It is depressing, but a lot of the work you do will be thrown away after 5 years. I get to keep and re-use the module documentation, the source code, and the unit tests. Having the module documentation up to date after long period of maintenance is unusual. It happens because I insist it is maintained as a comment in the source. The comment is sometimes 1000's of lines long. In C in would like in the .h file.
At first it seems archaic having all your
documentation in 12pt courier and manually
formatted. But the programmers come to
appreciate having the documentation regardless
of what it looks like, and since it is under
their noses in a format that is easy to change
they take the time to keep it up to date. The
same applies to the unit tests and their
results.
This leaves the initial design document, the system tests, and the beta testing as either not re-usable or is ignored and hence just withers and dies. You could re-use the system tests if you had a decent test harness that recorded and ran the tests. But in every one I have come across is not practical. It is not hard to write the first systems test. But as the system evolves the effort and expertise required to maintaining what is essentially a serial of key strokes and mouse clicks becomes overwhelming. It is less effort to maintain a set of test scripts written in English and run them manually. That is a pity, because it seems like you could save a huge amount of time if you could automate it.
Hmmm, I doubt anybody will read this far. But it is nice to get your development process down in black and white. I have not done it in a few years, so it was time to do it again. And it is ever so good of slashdot to keep a permanent record of it!
Possibly they got it wrong. Or possibly its because the American billion is 10^9, and the British billion is 10^12, or at least was when I went to school. It may of changed in 20 years.
Like all good troll's there is an element of truth in what Eric says. Microsoft can not sell Windows at its current price as the price of the hardware drops. But as others here point out, the solution for Microsoft is easy: they can just drop the price of Windows accordingly. And they are likely to do just that.
But they can't keep doing it. It takes a massive investment on Microsoft's part to keep churning out each generation of Windows. So there will be a point when they can't sustain that. My guess is that point will be reached only when "Mores Law" is laid to rest - probably in 10 years or so. The price of a PC will drop dramatically then, for a number of reasons. Intel and friends won't have to put in the massive investment for each new generation of chip. We can move things onto the motherboard because next years model won't be so different. There will be less variety and hence more competition from different manufacturers producing the same thing.
When that happens the price of a PC will be a fraction of what it is now. So the price of Windows will also have to be a fraction of what it is now. Perhaps developing the operating system won't look so attractive to Microsoft then.
Many posts here argue along the lines that "people buy computer gear for entertainment, the entertainment industry will only produce stuff for gear that has DRM, ergo companies who produce DRM hardware will sell more hardware than those that don't". Well they got one bit right. It is all about money, and I don't doubt that if the hardware people thought they could make more money by selling DRM gear, they would.
But they don't think that. They think the reverse. There are several good reasons for this:
The hardware companies aren't stupid. They know which side their bread is buttered on. They will oppose DRM all the way. Not for altruistic reasons, but for the very same reasons the entertainment industry wants DRM - they will make more money without it.
I was a bit surprised to see Lessig advocating 70 years after the person's death for non-published works. He generally takes the view that things should be released into the public domain as soon as practical, because then it becomes available fresh material for other to draw upon. Yes here he is advocating withholding a letter someone writes in his 20's for say another 120 years (assuming he lives to 70).
Letters and other personal correspondence are the primary source for biographers! Surely he does not advocate the primary sources of unauthorised biographers for 120 years?
Slashdot no different to other media outlets. The editors choose the stories (no doubt from the 100's that are suggested daily) that they think will appeal to their readers. If they did not do that well Slashdot would not be here.
I am not sure how they guage how appealing a story is, but in Slashdot's case one important metric is the number of posts a story gets. Without posts the story dies. Measured like this kernel releases make pretty good news stories for Slashdot. For example when I wrote this post the stories on the front page attracted an average of 285 posts each. This one had attracted 353 posts, which is well above the average.
In other words your comment "This is not major news - this is trivial for everyone except those who are experimenting with the new kernel or developing for it" is at best irrelevant. Apparently a lot of people do think kernel announcements make interesting news, and for that reason they will continue appear on Slashdot.
She continues to propergate the myth that most artists depend on copyright to earn their money. That is crap.
Here is a thought experiment. Think of all the artists that live in your local community and who earn their living through music. Initially most people this of artists like Brittany Spears, but she isn't local. The people on you list end up like this: the piano man at the local upscale restaurant, the music teachers who teach your kids at school, the city orchestra, the performers who play at weddings, the band at the school prom, the buskers in the city mall, the national anthem singer at the local football game. Now how many of those people depend or need copyright to earn their living? Unless you live in a big city the answer will be none. If you live in a big city you may have a band or two who has hit the big time - and then the answer will be a few percent.
If it is like that in your community it is going to be like that in most communities. Ergo most musicians don't give a rats about copyright. In fact most of them would make a better living - tyey would have to fork out less royalties if there were no copyright.
Perhaps you are having trouble believing this. Try the same argument with software. Most people on slashdot will know many more programmers than they know musicans. They may develop commercial packages, they may do in house work, they may write scripts to maintain networks or web pagesCopyright only effects those that develop commercial packages, who are a small percentage of the total. But how many of those people who develop software commercial packages actually depend on copyright to protect their income? Well I work for a firm that has developed several such packages. Like most such firms we developed a software package for a particular industry. The people in the industry know nothing about software or computers, so we don't just sell the software, we install and configure it, and then supply ongoing support. For the majority of our customers the software without this service would be useless. Ergo I and my fellow programmers don't need or depend on copyright.
Now there are of course programmers who work microsoft, borland, or some such company who this does not apply to - without copyright they would be out of a job. But you know what - I personally don't know any. In fact I can't think of a single software company in the state I live in that does depend on copyright. Its a small state - just 2-3M people. Within Australia there might be a couple of hundred programmers who do depend on copyright for their jobs. A couple of hundred out of 10's of thousands.
The argument based on the "poor struggling artist" is all hand waving and bullshit. Don't be sucked in.
I would go farther than than. Microsoft sells commodity software. Commodity software is software that changes little and is used by millions of people. In economic terms what happens to any commodity? Its price drops to the marginal cost of manufacture. For software that is the cost of stamping the cd. So in the long term it Microsoft's current business model is going to break.
Sounds far fetched? It's not really. Even Microsoft knows it. That is why they are pushing renting software rather than selling it. With renting they have an income stream without having to sell new software. I did not think they would succeed in renting software, until it dawned on me that already had succeeded with Windows. Why do you think you can't resell Windows when you sell your PC? I thought it was because Microsoft wanted get another sale of windows to the new owner. But no. It's so you can't reuse your Windows licence when you buy yourself a new machine. Effectively you are renting Windows for the life of the PC you bought.
However renting is only a short term solution. In the longer term competitors will come out of the wood work. In 5 to 10 years KDE Office/StarOffice/Gnome will be almost as good as Office. If it is not open source then it will be commercial in a longer time frame. But whatever. The trigger is having your revenue stream based on selling software that does not change, that has finished evolving, that you can no longer add features to make people upgrade. Office has reached that trigger and Windows can't be far away.
BTW, IBM is a total different kettle of fish. They sell hardware. In order to push their hardware they sell services, one of them happens to be software. IBM will install your software, customise it for you, and run your IT department if that is what you want. Like the other 99% of software companies in the world IBM sells a service, not a commodity. The contrast with Microsoft could not be more stark.
In order to survive in the long term Microsoft is going to have to change their business model completely. They are going to have to stop selling software and start selling services. I don't know it they will be able to do it - it is a huge cultural change. Unlike the rabid minority on Slashdot I think Microsoft has contributed a lot to the software engineering community. I wish them luck.
The original post said "KDE is still based on a lanugage with no support built in for objects", without giving a creditible alternative to C++. Then you come along and suggest C# - a language that is not available on Linux yet! Give us a break.
I am willing to bet that Microsoft produced C# as a response to Java, and more specifically Java's VM. Java's VM killed two birds with one stone - portability and security. An impressive acheivement. Notice that componentisation was not on the list. At the time Microsoft pushed ActiveX as an alternative - a component technology. It was haled as snake oil at the time. The snakes that later arose were Code Red/Nimda/SirCam/.....
This is an obviously correct and informated reply to the previous post. I guess the person who modded it down is a little wet behind the ears.
The orignal poster is correct, the primary advantage of garbage collection is run time saftey. A secondary advantage is convienence. These are two big wins. But in all other ways it looses out. It is slower, the run time of a program that uses it becomes less predictable, and because it blurs the point at which an object is destructed releasing other resources (like files) becomes problematic.
Oh, and C++ has had reflection (aka RTI) for some years. It is an add on - just like it is for Java.
I have used Word for some complex documents, and the results were not good. Things it did:
Don't get me wrong. Word is great at bashing out a 2 page letter, and not bad 10 page business proposal with pretty graphics and graphs. But over the decade or so I have used Word to create really large and complex documents my attitude have turned to fear and loathing. They are many packages out there (for both Windows and Linux) that are better than word for that sort of thing. I would not be surprised if StarOffice was one of them.
I remember when I first came across ASN.1 years ago. Everybody hated it because the parser was sssooo big and complex. Why not just use a simple ASCII file was a common refrain. Sure ASN.1 was capable of representing just about any data structure in a reasonably compact form, but most information did not need complex data structures to represent it so why does anybody use ASN.1?
Well a decade or two later we get the ASCII version of ASN.1 - XML. And guess what? It's arguably harder to write a generic parser for XML that it is for ASN.1. (I still have not found a good open source validating parser for XML.) But guess what - everybody is wildly enthusiastic this time round. My how times change!
Actually ASN.1 and XML in some ways are very similar. They try to solve the same problem - how to represent complex data structures in a generic way. And they do it in a similar way. Because ASN.1 is binary and uses numbers instead of text tags it does use a lot less space to represent the same thing, although 2 verus 200 bytes claim is at best misleading. Most of the 200 bytes would probably be XML header (dtd's and stuff) which you would not put in the ASN.1 encoding.
And yes, XML is too fat for some applications. For example, if you are pumping out a 60k row SQL table to your 1000 clients every day you probably would not choose XML. That is why this idea has merit. It could give you the benefits of XML without the fat. To work someone who have to come up with a standard way of translating a DTD to ASN.1 encoding. I know it's a good idea because I came up with it myself a while back :).
I am sure that if the patent really threatened to stop SAMBA development the SAMBA team would find ways around the problem. For example, they could provide an interface for an authentication "plug in" that was developed by somebody out of the reach of the patent. They could even write the plug in and make it available on a Web Site that is out of reach. Or most users could just ignore the patent. As I recall PGP has used all the of these techniques at one time or another to get around the RSA patents.
Actually the RSA / PGP example demonstrates that patents are not very effective against open source. It is far too easy to just more to the code development and distribution to a place the patent does not apply, and then rely on the users to ignore it.
Microsoft has a far more effective weapon available to it anyway - changing the protocol with every release. This has effectively nuked the NTFS driver for 'nix. It surprised me to hear that it causes SAMBA as much trouble as it does - I thought SMB would be very constrained by the existing client base. Obviously it is not constrained enough!
A number of posts here say something along the lines of "Code Red is malicious, it tried to attack the Whitehouse!". Sorry, I don't buy it. This is the type of damage a truly malicious virus does:
The thing is so benign it should be called a worm, not a virus. Anybody who things otherwise obviously has not seen the effects of a real virus attack on an organisation, or tried to clean up the consequences.
Here at work we have a lot of PC's running various versions of Windows, and a WAN network of Linux servers. The WAN covers most of Oz, so we can't visit these sites easily. The Window's machines are a PITA to support because each one is configured differently, so we looked at issuing a "Standard Operating Environment", based on Windows.
That idea was dropped fairly quickly when we realised that we would have to buy a new version of Windows for most machines, and that would cost many thousands of dollars. Actually the problem was worse than that as we have some standard apps we run on those machines, and in many cases that would have to be upgraded as well. The cost would be well in excess of $300 per machine.
Now as it happened we recently went to the some auctions to buy some machines. (Up till recently we had piles of recycled boxes lying in corners, but somehow they all used up, so it was time to buy some more.) We got some Dell 266Mhz 3Gb 64Mb boxes for AUD$300 each. More than enough to run Linux or Win9x and any office app. And there were piles of them there, all identical, more than we could ever use. We could outfit the entire organisation with these things.
It was then it hit me - the cost of just the base software, not including the office and accounting stuff, just the basic OS, virus scanners, and some Wan software, was more than the cost of the hardware. We could literally replace every office machine in the organisation with one of these things using a Linux based SOE for less that the cost of bringing the software up to a standard level on our existing hardware(!) In fact when you take into account that "older" hardware lasts 2-3 years and I would like to roll out a new "Standard Operating Environment" every year it is much cheaper.
We can't do it of course because the open source office apps aren't quite up to scratch yet. But the will be in time - roll on KOffice. Guess what I going to do then!
KFG - rarely do you see posts on slashdot that combine the humor, wit and obvious expertise that yours do here. I throughly enjoyed reading them. Well done!