I'd say your basic problem here is bad timing. Fedora Core 4 has only just come out, so the people who rally around and build all the useful add-on packages haven't had all that long to hammer on the problems. So at the time you installed Fedora Core 4 you would probably have been better off installing Fedora Core 3 instead. Give it a month or two and your experience with FC4 would probably be much better.
Obligatory dig at Windows: You probably wouldn't have had any less trouble if you'd tried to build a PVR on top of a week-old release of Windows - they just come along less often...
The only thing that bothers me is the amount of money the government wants me to pay for my new card and the amount of money they want for making changes to the card. Anything more than 0p is too much in my eyes.
Where do you get the uterly stupid idea that as long as the government don't charge you directly for being entered on the database and getting an ID card, it has no cost to you? You pay taxes (or will do at some point in your life time)? Do you seriously think that your taxes only go towards paying for the NHS and road building, and it's someone elses tax that's paying for the ID card scheme and the bit of plastic in your pocket?
The government is about to piss £5.5bn (and rising) of our money down the drain for no tanigble return on investment. There is no way that this could ever be done and cost you 0p. Get with the programme.
Inspectors were shown over a 9 year period to be ineffective.
Hmm; the weapons inspectors were there to prevent Iraq from having WMDs. After the war we find, lo and behold, no WMDs in Iraq. Not even evidence that they can point to to say "look, they were here".
So the inspectors were ineffective in what way, exactly?
The UN weapons inspection programme might have been a tedious, frustrating cat-and-mouse chase for everyone involved, but it still looks better than the alternative we have now.
I'm obviously missing something here: in the UK the reward for using the loyalty card is the money-off vouchers they send you in the post every few months. If they don't have your name and address you don't get the vouchers. But I can't believe that you'd actually be carrying and using a loyalty card for no reward whatsoever. So do you get for carrying the card without them being able to contact you?
Google employees are apparently allowed to work on their own projects 20% of the time. Given that you probably can't comment on what you're doing for Google, what are you doing to fill the other 20%?
The original post was written to answer the question "why is Sun carrying on developing Solaris rather than dumping its IP into Linux and using that instead?", and I think the reasons that have been put forward are good ones.
Unfortunately, in reading the post some people seem to be mistaking a business decision for a technical one.
Although it can leave you with a system that the Red Hat installer won't upgrade. If your root partition is actually an LVM logical volume or a RAID device, and it's formatted with reiserfs, the installer won't find your existing system and won't offer the upgrade option.
I want to be able to run the Oracle database for my work, and I've got a multi-head setup that Gnome 2.2 is supposed to handle much better than Gnome 2.0. I run Red Hat 8.0 at the moment; I could move to Red Hat 9 for Gnome 2.2, but Oracle doesn't work with the new threading system they've brought in.
I'm hoping XD2 gives me Gnome 2.2 on Red Hat 8.0 - anything else is a bonus.
"Great, but who will use them? Java has been out for 8 years now, and no one takes competing JREs seriously. If you want to write something without thinking about the tiny differences between your JRE and the one everyone else uses, you stick with the Sun's."
Rubbish! If you're in the part of the industry that doesn't just run applications on desktop boxes you're going to take Java's portability very seriously. Why? Does Sun provide a JRE for the Mac? IBM's pSeries RS/6000s? How about your zSeries mainframe? Or your Nokia mobile phone? Or your SGI box? Out here in the real world people take these other JVMs seriously.
The fact that I can performance test my code on multiple hardware platforms, multiple JVMs and multiple application servers, then make the decision about deployment, is exactly what makes Java important to me and the companies I work for.
"Even today, you better not try writing a Java compiler that compiles to anything but Java bytecode, or that extends the language."
What, you mean like
GCJ, that uses the gcc back-ends to compile Java to native code, or
Pizza, that adds generics, function pointers and algebraic types, or
GJ, which is the where the Java 1.5 generics support was prototyped.
No, better not try writing anything like that.
"They were very litigious in the beginning, suing Microsoft to keep them from messing with their platform. A platform they [Sun} fought fiercly to keep proprietary and closed."
I think we can both agree that Sun and Microsoft have tried (or will try) to use the law to protect their technical vision for Java and.Net respectively. The difference is in what that technical vision is. Sun sued Microsoft in order to make sure that different implementations of Java would be compatible across platforms, because that is their technical vision (remember "Write once, run anywhere?"). Microsoft are attempting to patent.Net, and the suspicion is that they will use it to prevent compatible implementations of.Net on different platforms. Now do you see the difference?
One way to try to improve this is to do some coverage analysis of your test suite. Basically you profile the code when you run the test suite and see how many basic blocks (chunks of code with only one entry point and exit point) you're hitting. You'd be surprised, but often a test suite that looks good will only hit 50% of the basic blocks in the code. The bugs that are found in the field will normally be in the basic blocks that weren't touched by the test suite. With a coverage analysis report you can try to write new tests that hit basic blocks that you haven't got already.
Your comment about corner cases hints at this: a corner case will usually come down to a path through the code that hits a basic block that hasn't been tested before.
Every artifact that you create, and then decide to keep, will need to be maintained over time. [...] Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. [...] a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.
Also check some of the practices, particularly "Discard Temporary Models" and "Update Only When It Hurts". In brief they suggest that you learn to throw things away when you've finished with them, minimise the number of models that you keep, and don't fret about making sure all your models are consistent just for the sake of it.
To me there's very little difference architecture-wise between client/server, n-tier, J2EE, web-services and so on. It all comes down to taking a single logical application and splitting it into chunks that can be reused separately and that can sit on different machines. The interesting thing is where you actually decide to split the application, and I think this is where client/server went wrong.
For the large-part, client/server was basically taking an application and putting the database on a central server, using ODBC, Oracle client or whatever to transport SQL over the network. It's the logical progression when you're used to writing VB applications using an Access database and you want to make your existing model work for lots of users.
What we're now seeing, though, is that splitting an application at the point where the business logic talks to the database is one of the worst places to do it, architecturally speaking. You finish up with your business logic bound to the presentation in a way that makes it difficult to reuse, and eventually you have multiple implementations of the same piece of business logic with a single database underneath it, and a whole bunch of inconsistency.
So J2EE, web services and so on are really about trying to make it easy for developers to split their applications into chunks somewhere between the presentation and the business logic, rather than between the business logic and the database.
But this new technology doesn't necessarily mean that people will understand the architecture any better. Just wait long enough and someone will miss the point completely and produce a piece of software that repackages ODBC, JDBC or something similar as a web service.
Are client/server applications dead? No. But you do need to have a migration path that allows you to extract the business logic as distinct software components so that you can re-use them in new applications. Whether you use web services or J2EE to help you do that is of little consequence. You could just write good libraries instead, as long as you get the conceptual architecture right.
A good migration path is one which will allow you to incrementally move business logic from your existing client/server front-end into a reusable middle-tier. Don't try to rip complex applications out and replace them wholesale - it's much more risky.
Projects seem to go one of two ways on code ownership issues: contributors assign ownership to the project maintainer (e.g. FSF projects), or contributors retain ownership of files they wrote (e.g. Linux kernel). Given that people are threatening you, it sounds like you're wanting to take ownership of the contributed code and distribute it.
The FSF have some good information on how to run a project, including a section on legal matters that covers getting the appropriate paper work from contributors before you integrate their code. Unfortunately I don't see how you get access to the actual text of the documents to replicate this process for yourself. Perhaps you could make your project an FSF project?
You can always use Ctrl-+ to increase the text size, which is nice.
Check for interrupt clashes, and test
on
Linux Tuning Tricks?
·
· Score: 5, Insightful
We recently built a machine around an Abit VP6 with 5 hard disks on it (three on the main IDE controller, 2 on the HighPoint 370 secondary controller). After a few days I noticed we were getting bad blocks on the drives on the HighPoint controller. Running badblocks on the disks gave random errors all over the place.
I then noticed that the Ethernet card was being given the same IRQ as the IDE controller and got suspicious. I swapped the ether card into different PCI slots until it got its own IRQ, then ran the badblocks check again. Everything ran clean.
It's also entertaining to use lmbench to test your hardware: it can plot pretty graphs showing how the IO speed changes across the disk surface so you can decide where to put your partitions, if that's important to you.
Main point though: if at all possible tune your hardware and then test using badblocks, lmbench and such before you put the machine into production (or when you've got a solid backup). As the article says, problems with your disk subsystem can loose lots of information quickly.
Using crypto to protect the APIs
on
What is .NET?
·
· Score: 1
One thing I'd not picked up until now is the use of public-key crypto to protect the APIs of software components (assemblies as they've called them). If I read it correctly, a piece of software will only link to components whose public keys it carries, so rather than just verifying interface compatability the CLR will verify that you're actually linking to the piece of code you developed against. This is probably considered a good thing.
This presumably also prevents people from writing compatible reimplementations of an assembly without a client program's co-operation. That's quite a major shift from previous systems (for example, you can replace and Java class by just overwriting the class file with a compatible replacement, and I believe the same's true with COM). Pretty useful if you want to prevent people from competing with you by producing compatible products.
So, let's say that Microsoft rewrite Word using.NET and release it. Does that mean that in order for Mono to run Word they'd need to re-implement all the.NET framework APIs and disable the cryptographic check to fool the code into working?
I used register.com recently and found the process pretty painless. I then moved the primary and secondary DNS entries to Granite Canyon's (free) Public DNS Service and set up my own RRs there. As a result I didn't need a whole lot of interaction with register.com, but everything went smoothly enough.
There's a sponsorship agreement between The Public DNS Service and register.com. If you're going to use register.com and might use the Public DNS Service, follow one of the links from the Public DNS Service to register.com so they get credit (and hopefully money) for the referral.
Slashdot Mirror
I'd say your basic problem here is bad timing. Fedora Core 4 has only just come out, so the people who rally around and build all the useful add-on packages haven't had all that long to hammer on the problems. So at the time you installed Fedora Core 4 you would probably have been better off installing Fedora Core 3 instead. Give it a month or two and your experience with FC4 would probably be much better.
Obligatory dig at Windows: You probably wouldn't have had any less trouble if you'd tried to build a PVR on top of a week-old release of Windows - they just come along less often...
The only thing that bothers me is the amount of money the government wants me to pay for my new card and the amount of money they want for making changes to the card. Anything more than 0p is too much in my eyes.
Where do you get the uterly stupid idea that as long as the government don't charge you directly for being entered on the database and getting an ID card, it has no cost to you? You pay taxes (or will do at some point in your life time)? Do you seriously think that your taxes only go towards paying for the NHS and road building, and it's someone elses tax that's paying for the ID card scheme and the bit of plastic in your pocket?
The government is about to piss £5.5bn (and rising) of our money down the drain for no tanigble return on investment. There is no way that this could ever be done and cost you 0p. Get with the programme.
-Mark.
Inspectors were shown over a 9 year period to be ineffective.
Hmm; the weapons inspectors were there to prevent Iraq from having WMDs. After the war we find, lo and behold, no WMDs in Iraq. Not even evidence that they can point to to say "look, they were here".
So the inspectors were ineffective in what way, exactly?
The UN weapons inspection programme might have been a tedious, frustrating cat-and-mouse chase for everyone involved, but it still looks better than the alternative we have now.
It looks as though someone's having a go at porting Compiere to MySQL here. I haven't tried running what they've produced so far, though.
-Mark.
I'm obviously missing something here: in the UK the reward for using the loyalty card is the money-off vouchers they send you in the post every few months. If they don't have your name and address you don't get the vouchers. But I can't believe that you'd actually be carrying and using a loyalty card for no reward whatsoever. So do you get for carrying the card without them being able to contact you?
Google employees are apparently allowed to work on their own projects 20% of the time. Given that you probably can't comment on what you're doing for Google, what are you doing to fill the other 20%?
The original post was written to answer the question "why is Sun carrying on developing Solaris rather than dumping its IP into Linux and using that instead?", and I think the reasons that have been put forward are good ones.
Unfortunately, in reading the post some people seem to be mistaking a business decision for a technical one.
Although it can leave you with a system that the Red Hat installer won't upgrade. If your root partition is actually an LVM logical volume or a RAID device, and it's formatted with reiserfs, the installer won't find your existing system and won't offer the upgrade option.
Or it is extended to read mail.
I want to be able to run the Oracle database for my work, and I've got a multi-head setup that Gnome 2.2 is supposed to handle much better than Gnome 2.0. I run Red Hat 8.0 at the moment; I could move to Red Hat 9 for Gnome 2.2, but Oracle doesn't work with the new threading system they've brought in.
I'm hoping XD2 gives me Gnome 2.2 on Red Hat 8.0 - anything else is a bonus.
Rubbish! If you're in the part of the industry that doesn't just run applications on desktop boxes you're going to take Java's portability very seriously. Why? Does Sun provide a JRE for the Mac? IBM's pSeries RS/6000s? How about your zSeries mainframe? Or your Nokia mobile phone? Or your SGI box? Out here in the real world people take these other JVMs seriously.
The fact that I can performance test my code on multiple hardware platforms, multiple JVMs and multiple application servers, then make the decision about deployment, is exactly what makes Java important to me and the companies I work for.
"Even today, you better not try writing a Java compiler that compiles to anything but Java bytecode, or that extends the language."
What, you mean like
- GCJ, that uses the gcc back-ends to compile Java to native code, or
- Pizza, that adds generics, function pointers and algebraic types, or
- GJ, which is the where the Java 1.5 generics support was prototyped.
No, better not try writing anything like that."They were very litigious in the beginning, suing Microsoft to keep them from messing with their platform. A platform they [Sun} fought fiercly to keep proprietary and closed."
I think we can both agree that Sun and Microsoft have tried (or will try) to use the law to protect their technical vision for Java and .Net respectively. The difference is in what that technical vision is. Sun sued Microsoft in order to make sure that different implementations of Java would be compatible across platforms, because that is their technical vision (remember "Write once, run anywhere?"). Microsoft are attempting to patent .Net, and the suspicion is that they will use it to prevent compatible implementations of .Net on different platforms. Now do you see the difference?
One way to try to improve this is to do some coverage analysis of your test suite. Basically you profile the code when you run the test suite and see how many basic blocks (chunks of code with only one entry point and exit point) you're hitting. You'd be surprised, but often a test suite that looks good will only hit 50% of the basic blocks in the code. The bugs that are found in the field will normally be in the basic blocks that weren't touched by the test suite. With a coverage analysis report you can try to write new tests that hit basic blocks that you haven't got already.
Your comment about corner cases hints at this: a corner case will usually come down to a path through the code that hits a basic block that hasn't been tested before.
Also check some of the practices, particularly "Discard Temporary Models" and "Update Only When It Hurts". In brief they suggest that you learn to throw things away when you've finished with them, minimise the number of models that you keep, and don't fret about making sure all your models are consistent just for the sake of it.
To me there's very little difference architecture-wise between client/server, n-tier, J2EE, web-services and so on. It all comes down to taking a single logical application and splitting it into chunks that can be reused separately and that can sit on different machines. The interesting thing is where you actually decide to split the application, and I think this is where client/server went wrong.
For the large-part, client/server was basically taking an application and putting the database on a central server, using ODBC, Oracle client or whatever to transport SQL over the network. It's the logical progression when you're used to writing VB applications using an Access database and you want to make your existing model work for lots of users.
What we're now seeing, though, is that splitting an application at the point where the business logic talks to the database is one of the worst places to do it, architecturally speaking. You finish up with your business logic bound to the presentation in a way that makes it difficult to reuse, and eventually you have multiple implementations of the same piece of business logic with a single database underneath it, and a whole bunch of inconsistency.
So J2EE, web services and so on are really about trying to make it easy for developers to split their applications into chunks somewhere between the presentation and the business logic, rather than between the business logic and the database.
But this new technology doesn't necessarily mean that people will understand the architecture any better. Just wait long enough and someone will miss the point completely and produce a piece of software that repackages ODBC, JDBC or something similar as a web service.
Are client/server applications dead? No. But you do need to have a migration path that allows you to extract the business logic as distinct software components so that you can re-use them in new applications. Whether you use web services or J2EE to help you do that is of little consequence. You could just write good libraries instead, as long as you get the conceptual architecture right.
A good migration path is one which will allow you to incrementally move business logic from your existing client/server front-end into a reusable middle-tier. Don't try to rip complex applications out and replace them wholesale - it's much more risky.
Projects seem to go one of two ways on code ownership issues: contributors assign ownership to the project maintainer (e.g. FSF projects), or contributors retain ownership of files they wrote (e.g. Linux kernel). Given that people are threatening you, it sounds like you're wanting to take ownership of the contributed code and distribute it.
The FSF have some good information on how to run a project, including a section on legal matters that covers getting the appropriate paper work from contributors before you integrate their code. Unfortunately I don't see how you get access to the actual text of the documents to replicate this process for yourself. Perhaps you could make your project an FSF project?
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
What does this mean?
You can always use Ctrl-+ to increase the text size, which is nice.
We recently built a machine around an Abit VP6 with 5 hard disks on it (three on the main IDE controller, 2 on the HighPoint 370 secondary controller). After a few days I noticed we were getting bad blocks on the drives on the HighPoint controller. Running badblocks on the disks gave random errors all over the place.
I then noticed that the Ethernet card was being given the same IRQ as the IDE controller and got suspicious. I swapped the ether card into different PCI slots until it got its own IRQ, then ran the badblocks check again. Everything ran clean.
It's also entertaining to use lmbench to test your hardware: it can plot pretty graphs showing how the IO speed changes across the disk surface so you can decide where to put your partitions, if that's important to you.
Main point though: if at all possible tune your hardware and then test using badblocks, lmbench and such before you put the machine into production (or when you've got a solid backup). As the article says, problems with your disk subsystem can loose lots of information quickly.
None of which have anything to do with JMS...
One thing I'd not picked up until now is the use of public-key crypto to protect the APIs of software components (assemblies as they've called them). If I read it correctly, a piece of software will only link to components whose public keys it carries, so rather than just verifying interface compatability the CLR will verify that you're actually linking to the piece of code you developed against. This is probably considered a good thing.
.NET and release it. Does that mean that in order for Mono to run Word they'd need to re-implement all the .NET framework APIs and disable the cryptographic check to fool the code into working?
This presumably also prevents people from writing compatible reimplementations of an assembly without a client program's co-operation. That's quite a major shift from previous systems (for example, you can replace and Java class by just overwriting the class file with a compatible replacement, and I believe the same's true with COM). Pretty useful if you want to prevent people from competing with you by producing compatible products.
So, let's say that Microsoft rewrite Word using
-Mark.
There's a sponsorship agreement between The Public DNS Service and register.com. If you're going to use register.com and might use the Public DNS Service, follow one of the links from the Public DNS Service to register.com so they get credit (and hopefully money) for the referral.