Although I don't like Microsoft's software and it's a real pain having to get all the latest patches, they do at least tell us when they've got a patch.
I don't know about Linux vendors in general, but Red Hat has offered such a notification service for years. You don't even have to pay them for it, just sign up for their security mailing list. I've been getting such notifications for a long time; I probably get a dozen a week.
"Microsoft deserves credit for having reduced the proportion of successful on-line hacker attacks perpetrated against Windows servers."
Well, that's sensible if you ignore the half million or so infections by Blaster - which clearly this article does.
I think that any analysis of digital attacks that filters out malware is missing a huge part of reality. Certainly you'd have to be nuts to call August a good month for Microsoft servers.
Re:Dead? Well, probably not. Mostly.
on
Java vs .NET
·
· Score: 1
I am fully aware of what it takes to write a Swing application, thanks, been doing that since Swing was a patch on JDK 1.1. You know why there are still several aftermarket UI frameworks? It's because Swing is really not commercial quality. The Java industry may not like to admit that, but I've been there and done that and I won't lie about it just because I don't like Microsoft.
I think that a large part of why Swing still has such bad quality is that people try so hard not to mention it that Sun actually believes they did a good job. But man, Swing is one of the worst UI frameworks I've ever had to deal with (and I worked with NeWS!)
In any case, I agree with you: If portability is your goal then Java is well worth a look. Then again, so are several C++ toolkits. IMO it's a wash as to whether the productivity boost you get from Java versus C++ beats out the productivity loss of Swing versus better designed and built toolkits in C++, especially since the C++ toolkits tend to interoperate much more cleanly with native applications. But YMMV.
In any case for most application designers portability is not their first goal. Often it's not even on the list, given that 95+% of all desktops are running Windows. And if you don't have to have portability, well, you're stupid if you're not considering the.NET platform these days. Even if you don't like Microsoft, and believe me I don't, it's too good to ignore.
If, however, you're building a server product -- well, let's just say that Windows is darn near my last choice for server applications.
Re:Dead? Well, probably not. Mostly.
on
Java vs .NET
·
· Score: 1
That sounds like AWT. They were trying hard to find some way to get OAK/Java associated with the Web, and the only way that would happen is if it integrated with browsers somehow, and the only way that made any sense is if it had graphics.
AWT was a thin attempt, and it shows. "Barely adequate" would be a good description. But with the exception of cut and paste and drag and drop it did at least mostly work and it was possible to build pretty sophisticated UIs with it. They just all looked and felt different from each other.
Swing was designed (and redesigned, and implemented and reimplemented). It shows in that its API is generally pretty clean, although there are some really bad warts like the table object (which just sucks).
Unfortunately for all the work they've put into Swing it has been notoriously low quality -- big, slow, and buggy. Very buggy. Nothing you couldn't work around if you spent the time, but hardly the epitome of UI construction environments either.
That is only partially true. It supports them only for a single web service endpoint, and there are quite a few limitations (including pathetically simplistic cookie handling). This is not nearly as useful as cross-endpoint session support.
The thing that's really crazy is that you'd think we would have learned that we needed sessions from our experiences with HTTP/HTML.
I note that it is not very hard to add full session support to Axis. Getting it into the various vendors' J2EE implementations is going to be a long haul though.
Re:Java vs. .Net
on
Java vs .NET
·
· Score: 2, Interesting
Heh, that's probably because Microsoft was sticking the.NET label on everything for awhile.
If you ignore that little bit of marketing idiocy then.NET comes down to being Microsoft's take on Java. In fact, it's derived from Microsoft's version of Java. When Sun sued Microsoft over compatibility issues Microsoft didn't just throw that work away, they changed it into.NET.
What they did, and this is clear from the VM language and APIs, is take the JVM pretty much intact and renamed the class library packages, classes, and methods using a slightly different naming scheme. If you know JDK 1.1 you are already familiar with a lot of the.NET foundation classes except that the packages have moved around.
On top of that Microsoft added some data management classes (not all that different in concept to JDO), a hell of a lot of UI and forms-management classes, web service support, and lots of XML support. And of course they integrated this well with their IDE.
Aside from doing a very good job with UIs, ASP.NET is hugely improved over the previous version of ASP (which, IMO, was disgusting). They still have pretty minimalist support for sessions if you ask me, but then again stock J2EE isn't really any better.
So: It's Java, with extensions both Windows specific and generic, with multiple source languages, and a nice IDE that has a bunch of code generators built in.
Getting back to this stuff being derived from Microsoft's version of Java, I think that in the long term Sun's lawsuit against Microsoft for "polluting" Java (which, in any objective view, Netscape was far more guilty of) will prove to have been a very big mistake. Back when Microsoft was trying to do Java Sun at least could control to some degree what direction they went. By forcing Microsoft to abandon Java entirely they are trying very hard to leverage the technologies to their maximum advantage.
And, to put it bluntly, they are doing a much better job of it so far than Sun has. Sun still has a huge edge in many areas due to J2EE's maturity, but I wouldn't expect that to last all that long.
Personally I think this is great because it means that we're going to have to see rapid development of usable systems in Java land, something we really haven't seen in years.
Re:Dead? Well, probably not. Mostly.
on
Java vs .NET
·
· Score: 1
Swing was decent in concept, horrible in implementation. A great variety of other APIs in other languages do a better job. That's too bad, Sun certainly had the opportunity to do a good job, but that's the way it is.
Other than that I agree, MS GUI programming was in general a nightmare prior to.NET. But be aware that.NET programming is nothing at all like MFC programming. It's easy easy easy and the VS.NET tool generates code that is actually worth keeping.
I avoided MFC UI programming like the plague. I did a lot of Swing programming (and AWT programming prior to Swing) and found it passable, but not really production quality, and of course it's quite tedious. I'm no Microsoft booster so believe me when I tell you.NET is terrific in this respect, a home run.
Re:Java vs. .Net
on
Java vs .NET
·
· Score: 4, Interesting
After all, it hasn't during the 3 years its been out.
Technically.NET wasn't released until a year ago last spring. It's only been out about 18 months. Last fall it was clear that people using.NET were very early adopters, but uptake seems very strong.
To be honest, Java on embedded devices doesn't seem like that big a win to me at the moment, no matter how many cellphones they're trying to ship with it. Most Java in use is on the server side. And that is a big differentiator between Java and.NET: Java runs on pretty much any hardware you care to throw at it, which means you can scale your server from that itty-bitty Pentium box up to the biggest stuff Sun sells. With Windows you've got midrange Intel boxes and... midrange Intel boxes. Little per-box scalability, and that means that large systems are going to be a pain to manage - particularly given how hard it is to manage Windows servers in bulk.
I can see.NET being useful for small servers that need to be put together quickly and cheaply; VS.NET is great for that. But it's not really there yet for big systems, both in terms of framework maturity and OS scalability and stability.
Mostly I think we'll see.NET be used in building GUI applications in the near term. Let there be no mistake, it is phenomenal at that.
Dead? Well, probably not. Mostly.
on
Java vs .NET
·
· Score: 2, Insightful
I've been using.NET for the last year on various projects, and Java since 1995, and I've come to a few basic conclusions.
If it's UI-based,.NET blows the doors off of Java. The design tools are so much better and the UI objects actually work the way they're supposed to. Swing is one royal PITA if you ask me, with lots of bizarre implementations, bugs, and poor interoperability with the native windowing system in many if not most cases.
If it's server based then J2EE holds an upper hand in more than just portability. Most of the J2EE containers out there have application build environments that are at least as good as VS.NET and since they tend to run on more scalable hardware they're easier to deploy for large sites. Various mature application frameworks are available too.
.NET beats the tar out of Java client-side web services. They're all about equal on the server side IMO. But on the client.NET has client stubs that support HTTP sessions (/very/ nice, but not part of JAX-RPC or even Axis) and VS.NET's integrated client stub generator is just a dream to work with.
The thing to remember about.NET is that it's really Microsoft's Java repackaged in a form that Sun can't sue them over. It has most of the JDK 1.1 libraries pretty much intact but with package and method names changed. But they did a very nice job in fixing a lot of issues that Java has.
In particular.NET's assembly management beats the heck out of collections of jar files.
YMMV, but if you're building a client and you don't absolutely need multi-OS support then you should really look at.NET. If you're building a small server it's probably worth a look too, ASP.NET forms are very easy to construct and they have decent tools for working with MSQL. But if you want a large-scale system I would not consider it, they need to work a lot harder on deployment issues and scalability of the base OS.
But I don't see how any of this applies to RIAA - using hashing to identify sound or video files is a retarded idea since slightest alterations in the files will produce radically different signatures (that's what secure hashing is)
That's exactly why what they're doing is such a good idea. Hashing is a great way to rapidly compare two files for equivalence. They can easily build up a database of content that's out there and quickly compare new content to existing content to determine probable relationships. It's not perfect, a match doesn't necessarily indicate a direct copy or even the same content, but it's going to severely reduce the amount of stuff they have to manually sort through.
It's particularly good since minor differentiations in file content -- such as errors during the ripping process -- will alter the hash result. These differntiations allow you to easily track different versions.
Where the RIAA will have issues is that, hash or no, two people can use the same ripping/compressing tool with the same settings, same song database, and enforce clean data extraction in which case the resulting file will be identical. In that case it'll be difficult for the RIAA to prove provenance or any other relationship, which is probably why they said that it can "sometimes" be used.
I would not be terribly surprised if "sometimes" works out to be "more often than not." It will depend a lot on how much effort people put into getting a clean rip. I don't know about you, but I want fast rips more than I care about clean rips (the idea being that if it's too terrible I can re-rip individual songs with lower error tolerance). I'd guess that a pretty large number of my files would have unique identifiers due to minor read errors. If that's the case then tracking isn't going to be terribly hard. It would be a neat research project to rip a couple of different copies of the same CD on different computers with the same software and default settings and see just how often you get mismatches.
But sometimes you don't even have to rely on errors. In the case they're talking about there were specific tags in the file to identify the source. While it's still possible for the woman to have inserted the same tags, used the same tools and settings, and used the same song database the combination of these things is pretty unlikely. And it becomes more unlikely the more such disparate tags or encoding mechanisms are found in her collection. If I were to make a bet I'd bet that she loses and that's why. Moreover, this issue is likely to be the bane of a lot of people who bear the brunt of an RIAA lawsuit.
And, frankly, I don't see why she and people like her don't deserve to lose. Do you file traders really believe it's your right to get this stuff without paying for it? Simply because the RIAA is charging too much? It's hard to see why such copying is either legally or morally justified.
While I strongly support the right for people to burn their own collections (clearly fair use) it really is theft to download these things. While I am not sure the penalties are appropriate ($150,000 per infringement is way out of line with the actual value of many tracks; that's more appropriate for wholesale CD duplication) some penalty seems in order in cases where bulk copying (as opposed to pre-purchase sampling) can be shown.
The good thing about P2P is it is putting pressure on the music industry to break out of the box of supplying only CD media, particularly at over-inflated prices made possible only because they have an effective monopoly. They're trying the legal approach to curbing P2P now, but that's untenable in the long term. They have to find a new business model that allows them to leverage the same technologies that make P2P possible to produce revenue without pricing things such that the risks associated with P2P (possible legal action) outweigh the benefits (free music) for users.
Generally speaking I agree with your commentary, although we do need legislation if only to give a lever that individuals can use when tracking these people down.
Right now if you want to track down a spammer you're pretty much SOL because you can't get a subpoena to extract identity information out of the ISP. You claim that it wouldn't help because they'll use stolen credit cards and whatnot; that may be true, however I was involved in a tracking operation where we tracked the guy to his office telephone because the ISP logged incoming telephone numbers in conjunction with call time and ID. It didn't matter if the ISP had his real identity, the phone company did.
This was a harassment case and obtaining a subpeona was no problem; had it been a spammer it would have been impossible. Giving us a legal foundation for tracking these people is the first step.
The important thing, for me, is not to outlaw spam outright; there are too many gotchas in doing that. We need legislation that normalizes it. Mandates things like no graphic sexual content in the mail message, no anonymity, and mandated opt-out capability. Moreover, the latter could be used to add a tax to spammers; create an opt-out database that they have to pay to access, for instance.
If such legislation is enacted I'm sure we'll see some operations move offshore, but the thing to remember is that an offshore operation raises the costs of doing this substantially. Anything you can do to raise the cost of doing business, even slightly, is going to help dramatically in the case of the really bad spammers. The profit margin on a lot of those spams has to be razor thin.
In the end, though, I think we're going to need technological solutions -- primarily an authentication mechanism for mailers. If all we do is require an authenticatable signature to SMTP traffic (eg signed "from" line) we will vastly decrease their ability to operate anonymously. For that to work all that needs to happen is a few large ISPs buy in on it and start denying unsigned traffic. You'll get a cascade of migration because if you don't migrate you lose a lot of connectivity. Moreover, the infrastructure to do this already exists, it was developed for browsers, all we have to do is leverage it with a small extension to SMTP.
What's clear at this point is that what doesn't work is ignoring the problem. I'm seeing SPAM increase at the rate of something like 25% per month on my personal account. At that rate even with sophisticated filtering technologies -- my filter system is exceeding 97% accuracy -- the 3% that get through will start to be a real burden in less than 18 months (to say nothing of the cost of the traffic that's being automatically dumped in terms of my DSL bandwidth).
I don't expect that legislation will be 100% effective, but if it takes out a few spammers and blunts the growth rate overall then it will be dramatically effective.
Well, it's nice that it's so strong in the longitudinal direction because it's really poor at handling torsional loads. You know, like when you're standing up and pedalling.
Anyway, bamboo and wooden bikes have been around for about a century. There are some reasons why metals and composites are used instead: Like weight, durability, and stiffness.
Other people responded to this, and it was the driver theft I was thinking of. I recall it being more than just a close copy of the structure of a device driver, but whatever the truth there was certainly unattributed derivation and it was necessary to do things to fix the IP issue. It was indeed resolved quite some time ago, though I don't recall how.
The point stands that we have seen unattributed BSD code in the Linux kernel in the past so it's possible there is more that nobody noticed.
Anyway, I'm not claiming this is definitely the case just that it's one possible explanation. SCO now says they've checked for possible BSD source but I'll believe it when we find out what code they're talking about and unrelated parties can check it out (or, better, we can see exactly who checked in the code and ask them).
I find it particularly interesting that they're claiming that significant stolen code is in stuff like NUMA support, which SVR4.1 did not have, or SMP support which SVR4.1 did remarkably poorly. These claims seem like they'd be difficult to substantiate.
I have no idea if there really is a BSD common root to that code, but it's at least one possible explanation. Hard for anyone to tell when they won't tell people what they think is stolen.
As the other guy said, you rewind using the skip-back-8-seconds feature. The end result is the ability to skip two to five minutes of commercials in four or five seconds.
One thing we've noticed is that some shows no longer have constant length commercial breaks. You get used to hitting "skip" 4 times for a 2 minute break, then they throw in a 1:30 break instead and you overshoot by 30 seconds. That takes a lot more "skip back" presses to reset.
While you have a point, my guess is that most people aren't interested in spending $200+ for something that appears at the outset to be roughly equivalent to what they get with a $50 VCR.
Plus you get to pay either a high one-time fee or a moderately high monthly fee for the service.
In other words, the price point is too high for a lot of people and that affects penetration.
'Course if you do have a Tivo you'll find that it changes the whole way you watch TV. I didn't believe it until I tried it.
Using the skip-30-seconds feature and the replay-last-ten-seconds feature we find that we can blow through several minutes of commercials, overshoot, and back up to the couple of seconds prior to the show in about four seconds per commercial break.
One thing that I've found interesting is that, despite the fact that I have the Tivo set up to blip forward 30 seconds to skip ads, is that something in an ad will catch my eye in the fraction of a second that it's onscreen before I blip forward and I'll go back and watch it.
It doesn't happen a lot, maybe once or twice an evening, but it kind of surprised me that I did it at all.
What's more, I still recognize most of the ads that I blip over from seeing them on "live" TV. I guess TV advertising is so redundant that I really only need a fraction of a second of the ad to recognize its content.
The 2-5% he guesstimated was total usage of bandwidth by SMTP.
One thing to remember is that the spam message may trigger a bunch of HTTP traffic; most spam messages these days contain HTML with embedded images.
This on top of the various nasty things that they're doing to get the SMTP message to the user in the first place.
If it were up to me, I'd suggest a three-fold approach to this problem. First, make falsification of e-mail headers and identities illegal. Second, make unauthorized use of relays illegal. (It's arguable that it already is, as that's unauthorized use of computing resources. Maybe we should start tracking and prosecuting.) Third, mandate opt-out.
The first two are critical to ensuring that we can hold spammers responsible, and for ensuring that they're at least paying for the bandwidth they're using. The third ensures that a concerned consumer can stop getting spam they don't want. I note that if we have a centralized opt-out database then you could charge spammers for its use per identity lookup, which would automatically control identity guessing and increase the cost of scaling spam... yet still keep it very affordable relative to paper mail.
I might additionally force spam to include the "Precedence: junk" header, which would help with filtering. I think, however, that by the time you get through the three layers of legitimizing the spam you'll cut the problem significantly because it will be a lot more expensive to send the stuff. Moreover, you'll have a lot more luck avoiding the DMA's lobbying efforts if you don't make it blindingly simple to filter out all spam.
A couple of years ago I was interviewed by a tech publication and asked what I thought Itanium's chances were. I told them if it was going to succeed, it would succeed on Linux' coattails. I figured that it would have no chance if it has to depend on Windows.
I still think that's true. Windows on Itanium is a terrible value proposition -- almost nothing will be native for years and years to come, and x86 execution mode is way way too slow to be cost effective. I think we'll see very little Windows on Itanium.
OTOH, Itanium is virtually ideal for vendors moving from proprietary chips/UNIXen to Linux. I was still fairly skeptical about Linux' chances back then, but I'm not anymore. Linux on Itanium is going to be a smash hit and will dominate the datacenter.
Windows on servers is... iffy. I see the possibility that AMD's x86-64 will be a hit in that market, but you'd have thought Athlon would be interesting too and it was completely ignored. Then again it's Microsoft's only real chance in the large server market so you can count on them pushing it really hard. If they succeed then expect an Itanium with a much improved x86 execution mode; I don't think Intel will go the extended-x86 route. If AMD does not succeed then Windows is going to be pigeonholed as a small server.
Regarding other chips, only POWER looks set to survive/thrive, but only in traditional IBM environments. Sun is in the middle of a financial collapse; I would be surprised if we see more than one additional generation of SPARC technology from them. Fujitsu has a nice SPARC, years ahead of Sun, but SPARC stuff is such a bad value proposition these days that it and Sun are going to die fast.
First, time is of the essence when building software. The faster you can build it and get it to market, the more money you make. And the faster you can modify and tune it, the more competitive you are in the long term.
If you can triple programmer productivity, even at a cost in performance, you can rapidly gain returns through improved algorithmics that overwhelm what you would have gotten from optimization.
Second, computing power has been multiplying over time. Back when Java first came out performance was a pretty significant issue. I was writing on a 100MHz Pentium box with 48M memory and, yea, sometimes it was pretty slow.
But that factor of three or so that I lost versus C++ got drowned out as the hardware grew to what we have today, with processors that are something like forty times as fast and memory sizes twenty or more times greater.
I'll take the productivity, thanks, and let Intel worry about the performance.
It is not my contention that it is impossible to do a 20 hour (or even 24 hour) day. Indeed, I would totally believe in a 48 hour session...but then my belief wanes (and one can't simply think "well what if you do a long session, then break, then a long session!?": The problem is that following a long session one generally crashes and crashes hard -- The net productivity over the period of combined heroics and crash evens out, if not falling on the negative side).
That, at least, I can entirely agree with. In every case where I did marathon sessions I was worthless for days afterwards. Over the long term I find it difficult to maintain more than a few hundred LOC per day on average.
My intent was to illustrate that 1,500 LOC in a day is not entirely unreasonable, it being a third of what I've managed at peak. But I entirely agree that sustaining it for more than a year is going to take a certain kind of individual, one I might label as "demented and sad" in Breakfast Club terms. I'm not willing to say it's impossible, though, because there certainly are individuals who can survive on little sleep for long periods of time (Edison was one).
Some of the issue may be in exactly what counts as a "line," and I don't really care to argue that issue, but...
I am not surprised you don't believe me. It's hard to believe it myself, and I'm the one that has done it. I do not suggest that that level of productivity is typical of either myself or others nor sustainable over a long period of time. My long-term average is less than a tenth that (and dropping as I get older).
The state I'm in when coding like that is best described as a fugue state. My mind is racing and everything else just gets ignored. Meals. Sleeping. I call it "going under" because that's what it feels like when I come out of it. The productivity that I see during such periods is prodigious to say the least.
But it's absolutely brutal on the body. You used a 16 hour day in your calculation, but that's understating it by nearly 50%. Because, in that state, I'm not sleeping at all. I'm incapable of sleep. Nor am I taking regular meal breaks. This allows coding for about 23 hours per day.
Typically when I get into that state it only lasts for about two days (40-50 hours), but there have been a handful of times when it has lasted longer... as many as five days straight.
As for whether or not the code produced was trivial, the last such time I did this I wrote a Java debugger from scratch. Mostly that was UI code (Swing didn't exist at the time so I had to write a lot of rendering and layout components) but the class disassembly and debug engines were fairly complicated (but nowhere near the complexity of a JPEG or MPEG decoder!). It took 96 hours to write almost 14,000 LOC.
Now, there are two other interesting productivity data points. When coding in C or C++ (doesn't really matter which) my productivity maxes out at around 1,500 LOC in a day. Java triples it! And the bug rate falls by ~90% in Java. I love Java.
Anyway, that's my story, believe it or not. And, as such, it's not entirely unbelievable to me that someone could do 1,500 LOC/day for at least a few days at a shot. Doing it for 18 months straight though? Doesn't seem likely.
I remember reading that IBM reckon that, including design, coding, testing, debugging and documentation, a programmer's doing well to get 10 lines of code per day, averaged over the life of the project.
From my software engineering course way back in college I think I remember the number being 4 or 5. But that is more like an industry average. One thing about software is that the best programmers are something like two to three orders of magnitude more productive than the average. Between that and the communication costs growing exponentially in a group you find that a few very talented programmers are vastly more productive than a mass of average programmers.
Still, sustaining 1,500 LOC per day for a year and a half... that's beyond the productivity level of anyone I've ever seen. I personally have managed 4,500 per day for a period of about a week on occasion... but I wasn't sleeping much during that period.
I am not sure I'd take that number at face value though. If this were real he would almost certainly be using a lot of prewritten code for codecs and the like and that would balloon the LOC for little effort on his part. It's more than a little unlikely that he'd be able to write all his own codecs in the first place.
So, while the LOC sounds specious, it's potentially believable given the probability of code reuse.
The thing that makes this entirely unbelievable is the performance claim. 4x performance of existing browsers over a 56k line? That's simply not possible since the bulk of time spent waiting is data transmission time. That could be improved but only with a server side component and it's doubtful it could be improved substantially without a large loss in quality.
I'm not going to dismiss the claim of a new web browser, but I'd be surprised if any of the size and performance claims hold water.
Slashdot Mirror
I don't know about Linux vendors in general, but Red Hat has offered such a notification service for years. You don't even have to pay them for it, just sign up for their security mailing list. I've been getting such notifications for a long time; I probably get a dozen a week.
Well, that's sensible if you ignore the half million or so infections by Blaster - which clearly this article does.
I think that any analysis of digital attacks that filters out malware is missing a huge part of reality. Certainly you'd have to be nuts to call August a good month for Microsoft servers.
I think that a large part of why Swing still has such bad quality is that people try so hard not to mention it that Sun actually believes they did a good job. But man, Swing is one of the worst UI frameworks I've ever had to deal with (and I worked with NeWS!)
In any case, I agree with you: If portability is your goal then Java is well worth a look. Then again, so are several C++ toolkits. IMO it's a wash as to whether the productivity boost you get from Java versus C++ beats out the productivity loss of Swing versus better designed and built toolkits in C++, especially since the C++ toolkits tend to interoperate much more cleanly with native applications. But YMMV.
In any case for most application designers portability is not their first goal. Often it's not even on the list, given that 95+% of all desktops are running Windows. And if you don't have to have portability, well, you're stupid if you're not considering the .NET platform these days. Even if you don't like Microsoft, and believe me I don't, it's too good to ignore.
If, however, you're building a server product -- well, let's just say that Windows is darn near my last choice for server applications.
AWT was a thin attempt, and it shows. "Barely adequate" would be a good description. But with the exception of cut and paste and drag and drop it did at least mostly work and it was possible to build pretty sophisticated UIs with it. They just all looked and felt different from each other.
Swing was designed (and redesigned, and implemented and reimplemented). It shows in that its API is generally pretty clean, although there are some really bad warts like the table object (which just sucks).
Unfortunately for all the work they've put into Swing it has been notoriously low quality -- big, slow, and buggy. Very buggy. Nothing you couldn't work around if you spent the time, but hardly the epitome of UI construction environments either.
The thing that's really crazy is that you'd think we would have learned that we needed sessions from our experiences with HTTP/HTML.
I note that it is not very hard to add full session support to Axis. Getting it into the various vendors' J2EE implementations is going to be a long haul though.
If you ignore that little bit of marketing idiocy then .NET comes down to being Microsoft's take on Java. In fact, it's derived from Microsoft's version of Java. When Sun sued Microsoft over compatibility issues Microsoft didn't just throw that work away, they changed it into .NET.
What they did, and this is clear from the VM language and APIs, is take the JVM pretty much intact and renamed the class library packages, classes, and methods using a slightly different naming scheme. If you know JDK 1.1 you are already familiar with a lot of the .NET foundation classes except that the packages have moved around.
On top of that Microsoft added some data management classes (not all that different in concept to JDO), a hell of a lot of UI and forms-management classes, web service support, and lots of XML support. And of course they integrated this well with their IDE.
Aside from doing a very good job with UIs, ASP.NET is hugely improved over the previous version of ASP (which, IMO, was disgusting). They still have pretty minimalist support for sessions if you ask me, but then again stock J2EE isn't really any better.
So: It's Java, with extensions both Windows specific and generic, with multiple source languages, and a nice IDE that has a bunch of code generators built in.
Getting back to this stuff being derived from Microsoft's version of Java, I think that in the long term Sun's lawsuit against Microsoft for "polluting" Java (which, in any objective view, Netscape was far more guilty of) will prove to have been a very big mistake. Back when Microsoft was trying to do Java Sun at least could control to some degree what direction they went. By forcing Microsoft to abandon Java entirely they are trying very hard to leverage the technologies to their maximum advantage.
And, to put it bluntly, they are doing a much better job of it so far than Sun has. Sun still has a huge edge in many areas due to J2EE's maturity, but I wouldn't expect that to last all that long.
Personally I think this is great because it means that we're going to have to see rapid development of usable systems in Java land, something we really haven't seen in years.
Other than that I agree, MS GUI programming was in general a nightmare prior to .NET. But be aware that .NET programming is nothing at all like MFC programming. It's easy easy easy and the VS.NET tool generates code that is actually worth keeping.
I avoided MFC UI programming like the plague. I did a lot of Swing programming (and AWT programming prior to Swing) and found it passable, but not really production quality, and of course it's quite tedious. I'm no Microsoft booster so believe me when I tell you .NET is terrific in this respect, a home run.
Technically .NET wasn't released until a year ago last spring. It's only been out about 18 months. Last fall it was clear that people using .NET were very early adopters, but uptake seems very strong.
To be honest, Java on embedded devices doesn't seem like that big a win to me at the moment, no matter how many cellphones they're trying to ship with it. Most Java in use is on the server side. And that is a big differentiator between Java and .NET: Java runs on pretty much any hardware you care to throw at it, which means you can scale your server from that itty-bitty Pentium box up to the biggest stuff Sun sells. With Windows you've got midrange Intel boxes and ... midrange Intel boxes. Little per-box scalability, and that means that large systems are going to be a pain to manage - particularly given how hard it is to manage Windows servers in bulk.
I can see .NET being useful for small servers that need to be put together quickly and cheaply; VS.NET is great for that. But it's not really there yet for big systems, both in terms of framework maturity and OS scalability and stability.
Mostly I think we'll see .NET be used in building GUI applications in the near term. Let there be no mistake, it is phenomenal at that.
If it's UI-based, .NET blows the doors off of Java. The design tools are so much better and the UI objects actually work the way they're supposed to. Swing is one royal PITA if you ask me, with lots of bizarre implementations, bugs, and poor interoperability with the native windowing system in many if not most cases.
If it's server based then J2EE holds an upper hand in more than just portability. Most of the J2EE containers out there have application build environments that are at least as good as VS.NET and since they tend to run on more scalable hardware they're easier to deploy for large sites. Various mature application frameworks are available too.
The thing to remember about .NET is that it's really Microsoft's Java repackaged in a form that Sun can't sue them over. It has most of the JDK 1.1 libraries pretty much intact but with package and method names changed. But they did a very nice job in fixing a lot of issues that Java has.
In particular .NET's assembly management beats the heck out of collections of jar files.
YMMV, but if you're building a client and you don't absolutely need multi-OS support then you should really look at .NET. If you're building a small server it's probably worth a look too, ASP.NET forms are very easy to construct and they have decent tools for working with MSQL. But if you want a large-scale system I would not consider it, they need to work a lot harder on deployment issues and scalability of the base OS.
That's exactly why what they're doing is such a good idea. Hashing is a great way to rapidly compare two files for equivalence. They can easily build up a database of content that's out there and quickly compare new content to existing content to determine probable relationships. It's not perfect, a match doesn't necessarily indicate a direct copy or even the same content, but it's going to severely reduce the amount of stuff they have to manually sort through.
It's particularly good since minor differentiations in file content -- such as errors during the ripping process -- will alter the hash result. These differntiations allow you to easily track different versions.
Where the RIAA will have issues is that, hash or no, two people can use the same ripping/compressing tool with the same settings, same song database, and enforce clean data extraction in which case the resulting file will be identical. In that case it'll be difficult for the RIAA to prove provenance or any other relationship, which is probably why they said that it can "sometimes" be used.
I would not be terribly surprised if "sometimes" works out to be "more often than not." It will depend a lot on how much effort people put into getting a clean rip. I don't know about you, but I want fast rips more than I care about clean rips (the idea being that if it's too terrible I can re-rip individual songs with lower error tolerance). I'd guess that a pretty large number of my files would have unique identifiers due to minor read errors. If that's the case then tracking isn't going to be terribly hard. It would be a neat research project to rip a couple of different copies of the same CD on different computers with the same software and default settings and see just how often you get mismatches.
But sometimes you don't even have to rely on errors. In the case they're talking about there were specific tags in the file to identify the source. While it's still possible for the woman to have inserted the same tags, used the same tools and settings, and used the same song database the combination of these things is pretty unlikely. And it becomes more unlikely the more such disparate tags or encoding mechanisms are found in her collection. If I were to make a bet I'd bet that she loses and that's why. Moreover, this issue is likely to be the bane of a lot of people who bear the brunt of an RIAA lawsuit.
And, frankly, I don't see why she and people like her don't deserve to lose. Do you file traders really believe it's your right to get this stuff without paying for it? Simply because the RIAA is charging too much? It's hard to see why such copying is either legally or morally justified.
While I strongly support the right for people to burn their own collections (clearly fair use) it really is theft to download these things. While I am not sure the penalties are appropriate ($150,000 per infringement is way out of line with the actual value of many tracks; that's more appropriate for wholesale CD duplication) some penalty seems in order in cases where bulk copying (as opposed to pre-purchase sampling) can be shown.
The good thing about P2P is it is putting pressure on the music industry to break out of the box of supplying only CD media, particularly at over-inflated prices made possible only because they have an effective monopoly. They're trying the legal approach to curbing P2P now, but that's untenable in the long term. They have to find a new business model that allows them to leverage the same technologies that make P2P possible to produce revenue without pricing things such that the risks associated with P2P (possible legal action) outweigh the benefits (free music) for users.
I think we can liken that to the movie industry.
Right now if you want to track down a spammer you're pretty much SOL because you can't get a subpoena to extract identity information out of the ISP. You claim that it wouldn't help because they'll use stolen credit cards and whatnot; that may be true, however I was involved in a tracking operation where we tracked the guy to his office telephone because the ISP logged incoming telephone numbers in conjunction with call time and ID. It didn't matter if the ISP had his real identity, the phone company did.
This was a harassment case and obtaining a subpeona was no problem; had it been a spammer it would have been impossible. Giving us a legal foundation for tracking these people is the first step.
The important thing, for me, is not to outlaw spam outright; there are too many gotchas in doing that. We need legislation that normalizes it. Mandates things like no graphic sexual content in the mail message, no anonymity, and mandated opt-out capability. Moreover, the latter could be used to add a tax to spammers; create an opt-out database that they have to pay to access, for instance.
If such legislation is enacted I'm sure we'll see some operations move offshore, but the thing to remember is that an offshore operation raises the costs of doing this substantially. Anything you can do to raise the cost of doing business, even slightly, is going to help dramatically in the case of the really bad spammers. The profit margin on a lot of those spams has to be razor thin.
In the end, though, I think we're going to need technological solutions -- primarily an authentication mechanism for mailers. If all we do is require an authenticatable signature to SMTP traffic (eg signed "from" line) we will vastly decrease their ability to operate anonymously. For that to work all that needs to happen is a few large ISPs buy in on it and start denying unsigned traffic. You'll get a cascade of migration because if you don't migrate you lose a lot of connectivity. Moreover, the infrastructure to do this already exists, it was developed for browsers, all we have to do is leverage it with a small extension to SMTP.
What's clear at this point is that what doesn't work is ignoring the problem. I'm seeing SPAM increase at the rate of something like 25% per month on my personal account. At that rate even with sophisticated filtering technologies -- my filter system is exceeding 97% accuracy -- the 3% that get through will start to be a real burden in less than 18 months (to say nothing of the cost of the traffic that's being automatically dumped in terms of my DSL bandwidth).
I don't expect that legislation will be 100% effective, but if it takes out a few spammers and blunts the growth rate overall then it will be dramatically effective.
Anyway, bamboo and wooden bikes have been around for about a century. There are some reasons why metals and composites are used instead: Like weight, durability, and stiffness.
The point stands that we have seen unattributed BSD code in the Linux kernel in the past so it's possible there is more that nobody noticed.
Anyway, I'm not claiming this is definitely the case just that it's one possible explanation. SCO now says they've checked for possible BSD source but I'll believe it when we find out what code they're talking about and unrelated parties can check it out (or, better, we can see exactly who checked in the code and ask them).
I find it particularly interesting that they're claiming that significant stolen code is in stuff like NUMA support, which SVR4.1 did not have, or SMP support which SVR4.1 did remarkably poorly. These claims seem like they'd be difficult to substantiate.
I guess it'll all come out in court.
I have no idea if there really is a BSD common root to that code, but it's at least one possible explanation. Hard for anyone to tell when they won't tell people what they think is stolen.
One thing we've noticed is that some shows no longer have constant length commercial breaks. You get used to hitting "skip" 4 times for a 2 minute break, then they throw in a 1:30 break instead and you overshoot by 30 seconds. That takes a lot more "skip back" presses to reset.
Plus you get to pay either a high one-time fee or a moderately high monthly fee for the service.
In other words, the price point is too high for a lot of people and that affects penetration.
'Course if you do have a Tivo you'll find that it changes the whole way you watch TV. I didn't believe it until I tried it.
Maybe 5 seconds if it's a long ad sequence.
Fast forwarding through them takes too long.
It doesn't happen a lot, maybe once or twice an evening, but it kind of surprised me that I did it at all.
What's more, I still recognize most of the ads that I blip over from seeing them on "live" TV. I guess TV advertising is so redundant that I really only need a fraction of a second of the ad to recognize its content.
One thing to remember is that the spam message may trigger a bunch of HTTP traffic; most spam messages these days contain HTML with embedded images.
This on top of the various nasty things that they're doing to get the SMTP message to the user in the first place.
If it were up to me, I'd suggest a three-fold approach to this problem. First, make falsification of e-mail headers and identities illegal. Second, make unauthorized use of relays illegal. (It's arguable that it already is, as that's unauthorized use of computing resources. Maybe we should start tracking and prosecuting.) Third, mandate opt-out.
The first two are critical to ensuring that we can hold spammers responsible, and for ensuring that they're at least paying for the bandwidth they're using. The third ensures that a concerned consumer can stop getting spam they don't want. I note that if we have a centralized opt-out database then you could charge spammers for its use per identity lookup, which would automatically control identity guessing and increase the cost of scaling spam ... yet still keep it very affordable relative to paper mail.
I might additionally force spam to include the "Precedence: junk" header, which would help with filtering. I think, however, that by the time you get through the three layers of legitimizing the spam you'll cut the problem significantly because it will be a lot more expensive to send the stuff. Moreover, you'll have a lot more luck avoiding the DMA's lobbying efforts if you don't make it blindingly simple to filter out all spam.
I still think that's true. Windows on Itanium is a terrible value proposition -- almost nothing will be native for years and years to come, and x86 execution mode is way way too slow to be cost effective. I think we'll see very little Windows on Itanium.
OTOH, Itanium is virtually ideal for vendors moving from proprietary chips/UNIXen to Linux. I was still fairly skeptical about Linux' chances back then, but I'm not anymore. Linux on Itanium is going to be a smash hit and will dominate the datacenter.
Windows on servers is ... iffy. I see the possibility that AMD's x86-64 will be a hit in that market, but you'd have thought Athlon would be interesting too and it was completely ignored. Then again it's Microsoft's only real chance in the large server market so you can count on them pushing it really hard. If they succeed then expect an Itanium with a much improved x86 execution mode; I don't think Intel will go the extended-x86 route. If AMD does not succeed then Windows is going to be pigeonholed as a small server.
Regarding other chips, only POWER looks set to survive/thrive, but only in traditional IBM environments. Sun is in the middle of a financial collapse; I would be surprised if we see more than one additional generation of SPARC technology from them. Fujitsu has a nice SPARC, years ahead of Sun, but SPARC stuff is such a bad value proposition these days that it and Sun are going to die fast.
First, time is of the essence when building software. The faster you can build it and get it to market, the more money you make. And the faster you can modify and tune it, the more competitive you are in the long term.
If you can triple programmer productivity, even at a cost in performance, you can rapidly gain returns through improved algorithmics that overwhelm what you would have gotten from optimization.
Second, computing power has been multiplying over time. Back when Java first came out performance was a pretty significant issue. I was writing on a 100MHz Pentium box with 48M memory and, yea, sometimes it was pretty slow.
But that factor of three or so that I lost versus C++ got drowned out as the hardware grew to what we have today, with processors that are something like forty times as fast and memory sizes twenty or more times greater.
I'll take the productivity, thanks, and let Intel worry about the performance.
That, at least, I can entirely agree with. In every case where I did marathon sessions I was worthless for days afterwards. Over the long term I find it difficult to maintain more than a few hundred LOC per day on average.
My intent was to illustrate that 1,500 LOC in a day is not entirely unreasonable, it being a third of what I've managed at peak. But I entirely agree that sustaining it for more than a year is going to take a certain kind of individual, one I might label as "demented and sad" in Breakfast Club terms. I'm not willing to say it's impossible, though, because there certainly are individuals who can survive on little sleep for long periods of time (Edison was one).
I am not surprised you don't believe me. It's hard to believe it myself, and I'm the one that has done it. I do not suggest that that level of productivity is typical of either myself or others nor sustainable over a long period of time. My long-term average is less than a tenth that (and dropping as I get older).
The state I'm in when coding like that is best described as a fugue state. My mind is racing and everything else just gets ignored. Meals. Sleeping. I call it "going under" because that's what it feels like when I come out of it. The productivity that I see during such periods is prodigious to say the least.
But it's absolutely brutal on the body. You used a 16 hour day in your calculation, but that's understating it by nearly 50%. Because, in that state, I'm not sleeping at all. I'm incapable of sleep. Nor am I taking regular meal breaks. This allows coding for about 23 hours per day.
Typically when I get into that state it only lasts for about two days (40-50 hours), but there have been a handful of times when it has lasted longer ... as many as five days straight.
As for whether or not the code produced was trivial, the last such time I did this I wrote a Java debugger from scratch. Mostly that was UI code (Swing didn't exist at the time so I had to write a lot of rendering and layout components) but the class disassembly and debug engines were fairly complicated (but nowhere near the complexity of a JPEG or MPEG decoder!). It took 96 hours to write almost 14,000 LOC.
Now, there are two other interesting productivity data points. When coding in C or C++ (doesn't really matter which) my productivity maxes out at around 1,500 LOC in a day. Java triples it! And the bug rate falls by ~90% in Java. I love Java.
Anyway, that's my story, believe it or not. And, as such, it's not entirely unbelievable to me that someone could do 1,500 LOC/day for at least a few days at a shot. Doing it for 18 months straight though? Doesn't seem likely.
From my software engineering course way back in college I think I remember the number being 4 or 5. But that is more like an industry average. One thing about software is that the best programmers are something like two to three orders of magnitude more productive than the average. Between that and the communication costs growing exponentially in a group you find that a few very talented programmers are vastly more productive than a mass of average programmers.
Still, sustaining 1,500 LOC per day for a year and a half ... that's beyond the productivity level of anyone I've ever seen. I personally have managed 4,500 per day for a period of about a week on occasion ... but I wasn't sleeping much during that period.
I am not sure I'd take that number at face value though. If this were real he would almost certainly be using a lot of prewritten code for codecs and the like and that would balloon the LOC for little effort on his part. It's more than a little unlikely that he'd be able to write all his own codecs in the first place.
So, while the LOC sounds specious, it's potentially believable given the probability of code reuse.
The thing that makes this entirely unbelievable is the performance claim. 4x performance of existing browsers over a 56k line? That's simply not possible since the bulk of time spent waiting is data transmission time. That could be improved but only with a server side component and it's doubtful it could be improved substantially without a large loss in quality.
I'm not going to dismiss the claim of a new web browser, but I'd be surprised if any of the size and performance claims hold water.