The switchboard demo reminded me. Have any of you Channers activated a product on the phone before? It's an automated system just like that. Being a real geek, I probably think it's way cooler than it actually is, but hey - I got a big kick out of it.
Next time you activate, try it over the phone!
(Note: the author of this post has no idea what really happened in regards to the kernel bug fix story and is merely using your example to show his point. Please don't bash me into the ground with mighty semantic issues.)
You're absolutely right. With the power of open source, a major bug was found and fixed!
The story doesn't end there.
So the kernel team fixed the bug. What happens now? How does the bug really get fixed? How does it propagate to every server and desktop out there? Is there an update system in place? What about for this distro over here? What about the guy who hasn't
patched since 3 minor versions ago since the new kernel 'broke his box that one time'? Are you just going to rely on the maintainers of all those distros to update and then get the updates to their users? Are you also going to rely on sysadmins to go out and
read the news and see that there's a new patch they need to apply and spend the next week figuring out why their 15 year old app now barfs on the new kernel? Seems like a mighty big buck you're passing around there.
The way I see it, that's the big difference between closed source and open source. Open source is pretty much all do-it-yourself. Some people have made kits, but you still gotta get your hands dirty and mangle the kit into your workspace and remember what manglings
you did to get it there (which can be pretty fun if you're not in a hurry or in a bad mood). But with closed source there's a company to take care of all that for you. If something isn't working,
They have to fix it for you since you gave them money for their software (despite how it often happens in the real world, that's the general idea). But then again, you have to wait for them to do it. You don't have the code
so you can't do it yourself. Then there's companies that bridge this gap and maintain open source things and make money only on support, but it's late and I don't quite feel like typing much more.
Yes, the fact that 'millions of eyes are looking over the code' does mean that more bugs get caught and fixed. But I think the open source community still has a long way to go in terms of doing all the other work needed after you hit compile, run your tests,
and check in for the night.
I'm not saying that Microsoft is the ultimate example of exemplary coding and bugfix deployment technology (though Windows Update is very nice) either.
And waaaaay back a bunch of posts, you said something about how X had network support and Windows Messaging didn't and you seemed to imply that it was sort of a handicap of Windows Messaging. Well, correct me if I'm horribly wrong, but doesn't X transfer screen
bits across the wire? Isn't that a little slow? And doesn't having this feature built-in tempt users to just use it instead of doing it the harder way and getting better performance? Just a thought - both ways have their advantages and disadvantages.
Totally sweet - Whidbey WinForms are lightyears ahead of everything else.
Can you guys make me a ControlList or something? I find myself wanting to make a 'list of controls', sort of like a custom-drawn listbox, but instead of having to write all that paint logic I can just point the list at a control type (or fill the list with
controls). That way I could have a button list, etc.
You do make great strides in this direction though. I'm currently abusing the FlowLayoutPanel to do just what I've described. But having to wire up event handlers for resizing can get to be a pain (god forbid I, a developer, actually write any code! <g>).
True, but did they simply add a switch to their compiler to do it?
(Note: I do know why you posted that comment. It was in response to the comment insinuating that you couldn't do such a feat inside the Java Virtual Machine. Your comment made no reservations about the way the program was ported, only that it is indeed possible
to run Quake II inside the Java Virtual Machine. I am merely saying that the .NET version was a quick add-a-switch-and-fix-a-few-bugs addon, while the Java version required rewriting portions of the code in Java.)
(Note: Did you see that the quake2java link is in fact pointing to a project with an empty CVS and no released files?)
Thank <applicable higher power>! I will make everyone I talk to about how a virus infected their computer watch this video. So glad to see that someone else out there still makes the distinction between virii, worms, and trojans!
I agree - tough decisions were made. But it's good that they made them. Assuming Longhorn were to be unchanged, we'd only get a client OS in 2007 with lesser versions of all the new features. Now we get a solid OS in 2006 and 2007, and the cool features
get to be backwards compatible. For an independent/hobby developer like me, waiting two or three years is a lot like waiting three or four. It's still way in the future, so another year to me is just a drop in the bucket so to speak.
I'm a little angry that there's no WinFS in Longhorn anymore, but the fact that you guys aren't going to release it until it's totally done (and that you haven't clipped it entirely) makes me happy again.
Like I said - tough decisions that had to be made. Here's to the Longhorn team for having the guts to make them!
I think this is a thing that third-party developers could step up and tackle (well, maybe not the intellisense bits, but who knows - VSIP seems pretty extensive...). It would be just like the new permcalc tool we heard about - walk through the MSIL looking
for throw instructions then trace back down to see the type of the object they threw. It would only get tricky if the code was doing something strange like create an exception and then throw it later on inside a loop or something. Tricky at parts, but extremely
doable. And once we can query a method to see what it throws, then we could just use reflection to blast through all the public and protected members of the framework and get a list of what everything throws for sure. Hey, we could even spit the list out
in XML! =P