While in general I agree that bugfixing tends to be fast in free software, I think PuTTY is a particularly exceptional case.
This is because Simon (and the rest of the PuTTY team, I suspect) basically won't sleep knowing there's a significant security flaw.
Considering this started off as just a way of getting a reasonable terminal emulator for Windows for personal use, I'm always amazed at how wide-spread PuTTY has become. Then again, it's a cracking piece of software.
I used to use the fact that Tim Curry played Monopoly with my dad when they were kids as my kudos-by-proxy. Now it's being mates with Simon:)
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
Interesting - I don't think I've ever heard exception handling referred to as event handling before. C#/.NET has very similar exception handling to Java, just without checked exceptions. (It also has the "using" statement which makes finally blocks extremely rare, and management of resources like files significantly simpler, IMO.)
Using listeners in Java isn't particularly difficult - it's just even easier and more elegant in C#.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
I'm *still* confused as to how you handle events. To me, event handling and exceptions are entirely separate things. I wouldn't handle a button click by throwing an exception (which is what Throwable is about). I would add a listener to the event - and that's the kind of event handling that.NET and C# have built into them, rather than just using plain interfaces and classes.
By the way, C# *is* an option for you on Linux - see http://www.mono-project.com. It's not the complete.NET framework, but the bulk of it's there, and there's GTK# for GUI applications.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
Apologies about the abstract business - I keep getting you mixed up with the person I originally replied to (especially when trying to post and sort other things out at the same time:)
If you really handle events by throwing exceptions, you've got the strangest exception handling code I've ever seen. Throwable isn't an interface though, it's a class.
If you could give an example of how you'd execute some listener code using the standard classes, that would help. JButton has addActionListener, for example. You implement ActionListener somewhere, subscribe to the event, and the code is executed when the button is clicked. C# is like that, except it has the model built into the language rather than just being a convention (although conventions are still involved, of course). Due to the way delegates work, you can listen for several actions in one class - no need for a separate implementation of ActionListener or the equivalent for each event. (Usually anonymous inner classes are used for this in Java, but that gets ugly pretty quickly, IMO.)
Properties make the code more readable just by getting rid of a lot of the gets/sets and brackets in your code. They aren't easily confused with fields because you shouldn't be exposing fields publicly anyway unless they're effectively constants (in which case, it doesn't matter whether they're implemented as properties or not). Before I started actually using C#, I thought this would be a problem too. It really isn't.
(One of the things I *dislike* about C# is implicit conversions - that really *can* make things confusing.)
Yes, I'm full of opinions, having used both languages thoroughly. (I haven't used Java for a while, but a groups.google.com search for skeet@pobox.com will show that I'm hardly a stranger to it.) Valuing both C# and Java has brought me flames in the past in both the Java and C# groups respectively, unfortunately.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
Yes, C# has an automated documentation system. It uses XML documentation, which can be processed in various ways, such as by ndoc.
Event handling - exceptions aren't at all the same thing as events. If you mean that Java has checked exceptions and C# doesn't, then it's certainly a matter of debate as to which is the better approach - I'm pretty much on the fence at the moment. C# still has exceptions, an exception hierarchy etc, just without the idea of checked exceptions. Again, I have to say I've never heard this called an event-handling model before now.
C# allows properties to be defined so they use the same kind of syntax as field access, but with methods being called behind the scenes. This makes for more readable code, IMO.
C# allows events to be defined which allow clients to subscribe and unsubscribe from those events, using delegates (another thing Java doesn't have). The list of subscribed delegates is then executed when the event is "fired" or "raised".
So, for instance, you might use:
someButton.Click += new EventHandler (HandleButtonClick);
These are pretty basic parts of C# - I don't think you can really comment sensibly on the language (or the.NET platform, which is where most of the above comes from really) if you don't know this kind of thing.
I note that you *still* haven't said in which way you find C# "abstract" compared with Java...
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
JavaDoc - C# has XML documentation Event-handling model - Java as a language doesn't have this at all Cross-platform - yes, Java has this over.NET, although it's not a *language* feature. (Whether Mono will end up providing the answer to this remains to be seen.) API documentation -.NET's documentation is pretty much as good as Java's, as far as I've seen. The layout is slightly less useful, but the information's still all there.
Java (as a language) *doesn't* have properties or events. It has conventions which some libraries use, but that's not the same thing.
So in short, you haven't provided any features which Java has over C#, as a language. Nor have you given any examples of ways in which C# is "abstract" (to use your term) where Java isn't.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
Events as in syntactic sugar for a way of adding/removing (and firing, although that's not supported by C#) delegates in a uniform manner.
When you do:
someButton.Click += new EventHandler (Whatever);
That kind of event.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 4, Insightful
So if you find C# abstract, where *exactly* is Java better, as a language? Or were you actually comparing the libraries? (Which bit of C# itself took hours for you to figure out?)
Personally I find them reasonably equivalent, but C# has a few advantages (properties, delegates, events) and the.NET library has had fewer iterations so is less internally inconsistent than the Java libraries at the moment.
A demo may well be a stripped down version (although it isn't always) - but stripping down costs time in itself.
Installation procedures (which often need to be slightly different for a demo than for the full game) need to be sorted out, inappropriate options need to be disabled, you've got to work out what to do when the player gets to the end of the demo, etc.
It's certainly an infinite set, sure - but the important thing is to be able to take one "nasty" thing to be effectively signed by finding one "nice" thing with the same hash. You don't need more than two things to have the same hash for it to be a problem.
I wasn't suggesting that collision attacks are perfectly acceptable - I was suggesting that one of the things to be signed could be perfectly acceptable (the "pretty standard" SSL certificate in your example while the other wouldn't.
I *think* this is the difference the article talked about between a preimage attack and a collision attack. An attacker still can't find a message (program, whatever) that produces the same hashcode as your one - but they *can* produce two messages which produce the same hashcode as each other. One of those may be perfectly acceptable, the other not - but once a user/system/whatever has accepted (or signed) the first one, they've effectively signed the second one.
That's only my impression based on the article, and I wouldn't like to swear to it - but it does make a certain amount of sense.
The name "survival time" suggests that it's the average amount of time an unpatched system would last before being compromised. That assumes that every single worm targets every single unpatched system, and is always successful. That's not exactly realistic - many worms target specific programs which may well not be on the unpatched system, or target specific operating system versions.
It would be much more interesting to see average compromise times for a vanilla install of various different OS versions (with no ISP protection, of course). In the mean time, the name should be changed, in my view.
I know what you mean - admittedly the problems with the databases I've seen haven't been security (usually) so much as just horrible design. Databases don't evolve cleanly:(
The great thing about using parameters though is that not only do they help to secure you against SQL injection attacks, they actually reduce the amount of work you need to do, too. For instance, suppose you have to put a date/time in the database. Using straight SQL this is a bit of a pain - you need to make sure you use the right format for the database etc. With parameters, it just drops out. Same goes for null values etc.
1) General security - yup, SPs win hands down here.
2) SQL injection attack - using prepared statements and parameters, this *shouldn't* be a problem with a Java or.NET app. (I would hope this functionality is available elsewhere too.) You don't write any of the parsing or formatting code - you let the DB vendor do that. (If they've screwed that up, of course, you're vulnerable - but then they might equally have screwed up SP security.)
Given an app which treats all user input as parameters rather than straight SQL, how is the application not secure from injection?
No, you don't have to pay, because they go on your white list - either implicitly due to you generating a stamp once, or explicitly because you tell them to add your server to their white list.
It would help if you read the FAQ, btw, which addresses this in more detail.
Yes, C# is only part of.NET. It's not the only part that has been submitted to ECMA though - there's ECMA 335 as well, which is the CLI, including the basic standard libraries. Of course, there's still more to.NET - the "standard" libraries are fairly small compared with what MS describes. Better than nothing though.
Yup, you can do that, I believe. You can even do it individually for the graphics card, the sound card, and the processor. Personally I've pretty much just left things on the defaults...
That really depends on what you're going to use your laptop for.
My laptop is my development and entertainment computer. I want it to be able to cope with XP and Visual Studio.NET (or Eclipse) pretty nippily, and still play music while it's doing so without stuttering. I want it to be able to compress music to MP3 without making it completely unusable while it's doing so.
My current laptop (Dell Inspiron 5150) does all of that fine. It has a reasonable battery life (3 hours or so if I'm not playing games), a reasonable graphics card (GeForce FX 5200 - not great, but not too bad) and 1Gb of memory to make up for the disk being slow. Its processor is nice and nippy at 3.06GHz, and having used a P3/733 for a long time, it *does* make a difference.
In terms of portability, most of the time I'm only carrying the laptop to/from the car, so it's not a problem. Lugging it around in the house is no hassle at all. It's heavy, but it's not like I'm running a marathon with it.
Basically, I'd rather go for heavy and powerful than light and slow - because of what I use my laptop for. Not everyone will want to use it in the same way as me, of course, but I'm pointing out that not everyone has the same priorities as you, either.
Because the full media centre PC would cost a great deal more than the "games only" box. MS has been stung this round by having a console which is expensive to make, and then having to cut the price to match the competition. The extras they'd need to make it a full media PC would be even more expensive. They'd need to work harder on making it quiet, they'd need a much bigger disk, they'd need to ship with a remote control, etc. For those who don't actually *want* a media PC, that's a lot of cost for no benefit. Including DVD playback in the XBox and PS2 was a similar kind of expense but a much smaller one. While it may well have helped to shift PS2s in the early days when DVD players were more expensive and less common, I'm not at all convinced it really helped the XBox to sell. (I'm not convinced it hurt the GC not to have it, either.)
So normal PS2s aren't selling in Japan any more, now that the PSX is available?
People don't want to spend more money on a console which has the same game-playing ability but also has features (such as PVR) which either they're not interested in or already have in another form.
Slashdot Mirror
What does it do? Bear in mind that the PuTTY team gets a *huge* amount of mail - it often takes them a long time to work through it.
While in general I agree that bugfixing tends to be fast in free software, I think PuTTY is a particularly exceptional case.
:)
This is because Simon (and the rest of the PuTTY team, I suspect) basically won't sleep knowing there's a significant security flaw.
Considering this started off as just a way of getting a reasonable terminal emulator for Windows for personal use, I'm always amazed at how wide-spread PuTTY has become. Then again, it's a cracking piece of software.
I used to use the fact that Tim Curry played Monopoly with my dad when they were kids as my kudos-by-proxy. Now it's being mates with Simon
Interesting - I don't think I've ever heard exception handling referred to as event handling before. C#/.NET has very similar exception handling to Java, just without checked exceptions. (It also has the "using" statement which makes finally blocks extremely rare, and management of resources like files significantly simpler, IMO.)
Using listeners in Java isn't particularly difficult - it's just even easier and more elegant in C#.
I'm *still* confused as to how you handle events. To me, event handling and exceptions are entirely separate things. I wouldn't handle a button click by throwing an exception (which is what Throwable is about). I would add a listener to the event - and that's the kind of event handling that .NET and C# have built into them, rather than just using plain interfaces and classes.
.NET framework, but the bulk of it's there, and there's GTK# for GUI applications.
By the way, C# *is* an option for you on Linux - see http://www.mono-project.com. It's not the complete
Apologies about the abstract business - I keep getting you mixed up with the person I originally replied to (especially when trying to post and sort other things out at the same time :)
If you really handle events by throwing exceptions, you've got the strangest exception handling code I've ever seen. Throwable isn't an interface though, it's a class.
If you could give an example of how you'd execute some listener code using the standard classes, that would help. JButton has addActionListener, for example. You implement ActionListener somewhere, subscribe to the event, and the code is executed when the button is clicked. C# is like that, except it has the model built into the language rather than just being a convention (although conventions are still involved, of course). Due to the way delegates work, you can listen for several actions in one class - no need for a separate implementation of ActionListener or the equivalent for each event. (Usually anonymous inner classes are used for this in Java, but that gets ugly pretty quickly, IMO.)
Properties make the code more readable just by getting rid of a lot of the gets/sets and brackets in your code. They aren't easily confused with fields because you shouldn't be exposing fields publicly anyway unless they're effectively constants (in which case, it doesn't matter whether they're implemented as properties or not).
Before I started actually using C#, I thought this would be a problem too. It really isn't.
(One of the things I *dislike* about C# is implicit conversions - that really *can* make things confusing.)
Yes, I'm full of opinions, having used both languages thoroughly. (I haven't used Java for a while, but a groups.google.com search for skeet@pobox.com will show that I'm hardly a stranger to it.) Valuing both C# and Java has brought me flames in the past in both the Java and C# groups respectively, unfortunately.
Yes, C# has an automated documentation system. It uses XML documentation, which can be processed in various ways, such as by ndoc.
.NET platform, which is where most of the above comes from really) if you don't know this kind of thing.
Event handling - exceptions aren't at all the same thing as events. If you mean that Java has checked exceptions and C# doesn't, then it's certainly a matter of debate as to which is the better approach - I'm pretty much on the fence at the moment. C# still has exceptions, an exception hierarchy etc, just without the idea of checked exceptions. Again, I have to say I've never heard this called an event-handling model before now.
C# allows properties to be defined so they use the same kind of syntax as field access, but with methods being called behind the scenes. This makes for more readable code, IMO.
C# allows events to be defined which allow clients to subscribe and unsubscribe from those events, using delegates (another thing Java doesn't have). The list of subscribed delegates is then executed when the event is "fired" or "raised".
So, for instance, you might use:
someButton.Click += new EventHandler (HandleButtonClick);
These are pretty basic parts of C# - I don't think you can really comment sensibly on the language (or the
I note that you *still* haven't said in which way you find C# "abstract" compared with Java...
JavaDoc - C# has XML documentation .NET, although it's not a *language* feature. (Whether Mono will end up providing the answer to this remains to be seen.) .NET's documentation is pretty much as good as Java's, as far as I've seen. The layout is slightly less useful, but the information's still all there.
Event-handling model - Java as a language doesn't have this at all
Cross-platform - yes, Java has this over
API documentation -
Java (as a language) *doesn't* have properties or events. It has conventions which some libraries use, but that's not the same thing.
So in short, you haven't provided any features which Java has over C#, as a language. Nor have you given any examples of ways in which C# is "abstract" (to use your term) where Java isn't.
Events as in syntactic sugar for a way of adding/removing (and firing, although that's not supported by C#) delegates in a uniform manner.
When you do:
someButton.Click += new EventHandler (Whatever);
That kind of event.
So if you find C# abstract, where *exactly* is Java better, as a language? Or were you actually comparing the libraries? (Which bit of C# itself took hours for you to figure out?)
.NET library has had fewer iterations so is less internally inconsistent than the Java libraries at the moment.
Personally I find them reasonably equivalent, but C# has a few advantages (properties, delegates, events) and the
A demo may well be a stripped down version (although it isn't always) - but stripping down costs time in itself.
Installation procedures (which often need to be slightly different for a demo than for the full game) need to be sorted out, inappropriate options need to be disabled, you've got to work out what to do when the player gets to the end of the demo, etc.
Then the whole thing needs to be tested.
It's certainly an infinite set, sure - but the important thing is to be able to take one "nasty" thing to be effectively signed by finding one "nice" thing with the same hash. You don't need more than two things to have the same hash for it to be a problem.
I wasn't suggesting that collision attacks are perfectly acceptable - I was suggesting that one of the things to be signed could be perfectly acceptable (the "pretty standard" SSL certificate in your example while the other wouldn't.
I *think* this is the difference the article talked about between a preimage attack and a collision attack. An attacker still can't find a message (program, whatever) that produces the same hashcode as your one - but they *can* produce two messages which produce the same hashcode as each other. One of those may be perfectly acceptable, the other not - but once a user/system/whatever has accepted (or signed) the first one, they've effectively signed the second one.
That's only my impression based on the article, and I wouldn't like to swear to it - but it does make a certain amount of sense.
The name "survival time" suggests that it's the average amount of time an unpatched system would last before being compromised. That assumes that every single worm targets every single unpatched system, and is always successful. That's not exactly realistic - many worms target specific programs which may well not be on the unpatched system, or target specific operating system versions.
It would be much more interesting to see average compromise times for a vanilla install of various different OS versions (with no ISP protection, of course). In the mean time, the name should be changed, in my view.
I don't think so.
c i283965,00.html
:)
PS3 plays PS2 games: PS3 is backwards compatible.
PS2 plays PS3 games: PS2 is forward compatible.
See http://whatis.techtarget.com/definition/0,,sid9_g
Of course, if you have an authoritative link which shows the rest of the world being wrong, I'd be very happy to see it
In terms of just the word "compatible", I'd say that the PS3 is compatible with PS2 games.
I know what you mean - admittedly the problems with the databases I've seen haven't been security (usually) so much as just horrible design. Databases don't evolve cleanly :(
The great thing about using parameters though is that not only do they help to secure you against SQL injection attacks, they actually reduce the amount of work you need to do, too. For instance, suppose you have to put a date/time in the database. Using straight SQL this is a bit of a pain - you need to make sure you use the right format for the database etc. With parameters, it just drops out. Same goes for null values etc.
Hang on a sec - you're conflating two issues:
.NET app. (I would hope this functionality is available elsewhere too.) You don't write any of the parsing or formatting code - you let the DB vendor do that. (If they've screwed that up, of course, you're vulnerable - but then they might equally have screwed up SP security.)
1) General security - yup, SPs win hands down here.
2) SQL injection attack - using prepared statements and parameters, this *shouldn't* be a problem with a Java or
Given an app which treats all user input as parameters rather than straight SQL, how is the application not secure from injection?
No, you don't have to pay, because they go on your white list - either implicitly due to you generating a stamp once, or explicitly because you tell them to add your server to their white list.
It would help if you read the FAQ, btw, which addresses this in more detail.
Yes, C# is only part of .NET. It's not the only part that has been submitted to ECMA though - there's ECMA 335 as well, which is the CLI, including the basic standard libraries. Of course, there's still more to .NET - the "standard" libraries are fairly small compared with what MS describes. Better than nothing though.
How are they mutually exclusive statements?
Here's an example of how it could have gone, for a particular month (with completely artbitrary figures - this is just a logical demonstration):
Week 1: GC 100, PS2 80
Week 2: GC 100, PS2 80
Week 3: GC 50, PS2 80
Week 4: GC 50, PS2 80
Total: GC 300, PS2 320
There, the GC led the PS2 for the first two weeks, but didn't lead for the whole month.
Is that so difficult to imagine happening for real?
Yup, you can do that, I believe. You can even do it individually for the graphics card, the sound card, and the processor. Personally I've pretty much just left things on the defaults...
That really depends on what you're going to use your laptop for.
.NET (or Eclipse) pretty nippily, and still play music while it's doing so without stuttering. I want it to be able to compress music to MP3 without making it completely unusable while it's doing so.
My laptop is my development and entertainment computer. I want it to be able to cope with XP and Visual Studio
My current laptop (Dell Inspiron 5150) does all of that fine. It has a reasonable battery life (3 hours or so if I'm not playing games), a reasonable graphics card (GeForce FX 5200 - not great, but not too bad) and 1Gb of memory to make up for the disk being slow. Its processor is nice and nippy at 3.06GHz, and having used a P3/733 for a long time, it *does* make a difference.
In terms of portability, most of the time I'm only carrying the laptop to/from the car, so it's not a problem. Lugging it around in the house is no hassle at all. It's heavy, but it's not like I'm running a marathon with it.
Basically, I'd rather go for heavy and powerful than light and slow - because of what I use my laptop for. Not everyone will want to use it in the same way as me, of course, but I'm pointing out that not everyone has the same priorities as you, either.
Because the full media centre PC would cost a great deal more than the "games only" box. MS has been stung this round by having a console which is expensive to make, and then having to cut the price to match the competition. The extras they'd need to make it a full media PC would be even more expensive. They'd need to work harder on making it quiet, they'd need a much bigger disk, they'd need to ship with a remote control, etc. For those who don't actually *want* a media PC, that's a lot of cost for no benefit. Including DVD playback in the XBox and PS2 was a similar kind of expense but a much smaller one. While it may well have helped to shift PS2s in the early days when DVD players were more expensive and less common, I'm not at all convinced it really helped the XBox to sell. (I'm not convinced it hurt the GC not to have it, either.)
The ability to view/hear what you want when you want doesn't *stop* you from lying around etc. It just means that you aren't forced to.
No-one's saying you've got to buy one of these, or even that if you've got one you have to use it all the time.
So normal PS2s aren't selling in Japan any more, now that the PSX is available?
People don't want to spend more money on a console which has the same game-playing ability but also has features (such as PVR) which either they're not interested in or already have in another form.