But a lot of [anti-privacy sentiment] comes from people who seem to genuinely believe that basic human rights are a threat to their security or to corporate profits
Well, speaking as someone who has occasionally expressed anti-privacy sentiment, my interest is not in my security or in corporate profits, but in whether or not privacy is a basic human right as you affirm.
There a strong feeling here on/. and elsewhere in the online community that privacy somehow is a fundamental right. This feeling is somewhat libertarian in nature, but interesting there's no libertarian philosophical literature that I can find that takes this position. Indeed, the politicians closest to holding this view are the sopping wet liberal bureaucrats of the European Commission.
The effects of increased and decreased privacy are quite complex, and since this is essentially a proposed addition (or corollary, or whatever) of the historically fundamental human rights, its worthy of more consideration than the knee-jerk reaction it generally gets.
Most of the concern appears to be around privacy from the state apparatus, on the implicit assumption that this provides protection from the enforcement of unjust laws. Its a remarkably weak and at the same time indiscriminate form of protection however.
On the one hand, privacy protections as a defence against law enforcement will inevitably result in an arms race where the state uses improved technology and enhanced legal powers to enforce its laws, and those trying to escape them try to invent more are more powerful protections to their privacy.
On the other hand privacy protections that protect those trying to form political parties, run cooperative enterprises, or trade MP3s will innevitably also protect those who really are international terrorists, theives and child pornographers.
The government will always be able to use the argument that it needs new powers to combat the evil of the day. Joe Bloggs and John Doe will believe them, and to some limited extent, they'll be right. Unfortunately, of course, the state can also use its powers to enforce laws that are not just.
This isn't a battle I want to fight, because I don't think we can win, and the reasons for fighting are weak at best. I think privacy's fundamentally not the issue. Restricting the state to its proper bounds is the issue, and privacy is a poor second best, surrounded by unintended consequences.
Re:As far as I can tell ...
on
MAPS vs. ORBS
·
· Score: 2
They didn't. At this point - if you go an check the usenet flamewar that errupted on this topic - its pretty clear that Telecom NZ (ORBS ISP) accidentally routed ORBS traffic to above.net, which was binning it (as was there right).
As far as I can tell ...
on
MAPS vs. ORBS
·
· Score: 2
Having trawled through everything that was posted on kuro5hin and the usenet posts on this subject, it seems that:
1. MAPS did indeed blackhole ORBS, but opinions seem to differ on whether it has stopped. ORBS is in the habit or testing random relays without asking permission or having evidence of their use for spamming. Rumour keep arising that ORBS also trawls IP-space looks for relays, and that it is impossible to get them to stop testing you, even if you ask (which gets you put on their static list of sites that refuse to be tested). The MAPS guys consider this to be net abuse.
2. Other than ORBS, everyone involved denies that above.net falsely advertised routes for ORBS traffic. Paul Vixie seems to think the misperception (or alternatively the maliciously false accusation) arose because Telecom NZ (ORBS service provider) chose the wrong way of routing ORBS traffic around above.net. Above.net have, however, blocked ORBS traffic in their own network, which they have a perfect right to do.
Re:Totally Unnecessary
on
MAPS vs. ORBS
·
· Score: 2
There were a couple of truly offensive posts (I'm not linking them because I don't think the person who wrote them deserves the publicity) going on about how/. had sold out and was censoring news, and managing to get some racism in there at the same time, posted in two stories including this one. I mailed rusty. I expect he'll zap them.
Thats probably what prompted michael to mention it. In general the/. haters are only a tiny minority on kuro5hin and their stories rarely make it to the main page.
Since kuro5hin is discussion-focussed and/. is news-focussed I think it is quite appropriate for stories to appear on k5 while they are still rumour, but not make it to/. till the fog has cleared. I personally which michael had waited till/. could be authoritative.
Clearly/. has not interesting in rubbishing k5, thats just paranoia. k5 is tiny in comparison, and in my view really *shouldn't* grow to/.'s size.
Yeah, you're right. Although he takes a very long time getting around to it, the parent post seems to be well confused about what constitutes a functional programming language. The author seems to thing they're equivalent to push-down automata (finite state machines with stacks, OK?), but this Just Ain't So.
The source of the confusion seems to be that he assumes functional programming languages are just fixed trees of recursing function calls. If this were so, he'd be right. They aren't, though.
Functional programming languages allow functions to be passed around as values, and these have full first-class status - so you have functions that take functions (which can do loops, or if-then-else constructions), and functions that return functions, which can do all kinds of funky stuff, including, importantly, functions that return a function that does the same thing, but with one parameters already set.
This seems to be what the author is getting at in his blather about "stream programming" and "deferred execution". Its not just a hack, though. Its the very heart of the lambda calculus - its how, in fact, you derive arithmetic from simple functions alone.
*However* the author is clearly a clever chap, and has obviously come up with all this stuff himself, so I say let him keep his mod points. Original thought should be encouraged - even when its wrong.
MacOS X is written on top of Darwin, which is Mach with a BSD-like personality layer on top of it. I heard someone was working on getting an X server working.
The point being that, while MacOS X software will not work on Unix, Unix software should work on MacOS as well as it works on Unix.
High performance != numerics. The authors of the paper you linked are interested in highly accurate floating point processing, something which is pretty rare. I'm unaware of anyone ever arguing that this was an appropriate use of the Java environment.
Similarly the paper you linked that "debunked" the WORA "myth" didn't. It just said it had been debunked. Server-side Java's WORA promise holds good (from wide personal experience, and industrial usage), client-side it is much easier to break *but* can still work.
JIT compilers can at times optimise better than ordinary compilers. For instance, they can perform data-dependent optimisations based on the data arriving during this particular run. OTOH (at least in Java) they can't perform optimisations that need lots of static type information as most of this has been lost. I don't consider the case proven either way.
Oh, and Java is "standardised" by Sun. While I agree that a language controlled by a commercial entity is unusual and potentially harmful its plain silly to make arguments about what "might happen when Java is standardised" as noone with clout has any incentive to push for this to happen.
Don't SHOUT, for goodness sake. We can hear you perfectly well. The most important clue to get here is that the developing world is more than one place - it is not all the same, it contains most of the world's people, and most parts of it are neither dangerous nor starving.
Because of the diversity of circumstances in developing countries, different things are appropriate to different people. Just the same applies in the west - in your case a lesson in elementary geography would probably help most, whereas to a teenage gang member in the south bronx, it would be largely irrelevant.
In the same way, there are people in many parts of the developing world whose biggest obstacles to improving themselves are lack of access to communications technology and education. These tend to be people whose elementary needs for food and moderately stable governance are taken care of, but who are excluded from the process of development by distance or by social and economic forces. Some Amerind tribes throughout the Americas fit this bill, as do some people in India and the stabler parts of Africa.
On the other hand, for the people who fit the stereotyped image of third-worlders, and are either starving or in fear for their lives from bandits, terrorists, geurillas or governments (it can be hard to distinguish), teaching then about Linux would indeed be inappropriate.
Nice troll. Two responses already. Perhaps not quite believable enough. 7/10.
Re:What's wrong with WAP? Here ya go.
on
WAP Under Fire
·
· Score: 2
How does a comment which does nothing but reiterate part of the story get moderated up to +4 ?
Re:Well suited to the job at hand
on
WAP Under Fire
·
· Score: 3
You're confusing the protocol WAP with the markup language WML. Most of the criticism in the story is about WAP, though there are also problems with WML. Given that Japanese DoCoMo mobiles can already present limited HTML content meaningfully, and have bigger screens and much better market penetration than WML phones anywhere, it seems to be that no good justification exists for WML's pandering to small screen size and assumptions about presentation. Location based services, and web pages integration phone functionality sound like things that could be integrated into the existing scheme of URLs and emphatically don't require a redesign from scratch of the whole protocol suite and a brand new markup language.
As the IETF paper points out, WAP itself (as opposed to WML) seems primarily to be marketing construct rather than a protocol with any significan technical benefits. It especially concerns me that some mobile phone operators will probably use the protocol diconnect between their own services and the real internet to act as "portals" and try to promote a closed content model rather than the traditionally open one of the internet.
If by "interpreter" you mean the native firmware that translates the target instruction set into native code (which isn't an interpreter, its a runtime compiler), then there is none for anything other than x86 code. The article you linked doesn't mention anything other than an x86 emulation, and there have been several hints that it would be quite hard.
You can't (obviously) take legal action in Sealand, and for the sake of argument we can assume their security is good enough that you can't take any kind of technical action, however my *point*, which seems to have missed you, was that (as the interviewee says) clients of HavenCo are still liable for their actions in their place of residence of country of citizenship.
In addition HavenCo itself of necessity has (or will have) legal and technical presences outside sealand, which will, depending on jurisdiction, be liable for legal and action, and to have information supeonaed from them. While they're bound to try to prevent this, its not at all obvious to me that they'll succeed.
They're not in international waters. Sealand is entirely surrounded by UK territorial waters no these extend to the 12 mile international limit. Sealand is either UK territory, in which case the inhabitants have the right to due process under UK law, or it a sovereign nation, in which case they can do their own thing.
Personally I think their claim to sovereignty is pretty solid, but I can think of plenty of situations where the UK or someone with tacit cooperation from the UK government (to get access to Sealand through UK territorial waters) would choose to brazen it out. From what Ryan says, it looks like they're going to try and avoid provoking anyone too much (for instance, he stresses legal liabiltiy in people's own jurisdictions), and this makes me feel happier about the whole venture than I did before.
Get a new credit card, I guess, but probably also try to find the person who owns the site. That might be doable throught whois, but more likely would require legal investigation. While HavenCo is probably registered in Anguilla, their peering agreements in the US might make some technical/legal action possible.
I've never seen a Linux distro as well locked down as OpenBSD. If you know of one, please let me know. When I refer to "Vanilla" Linux, I mean one of the more-or-less standard distributions (RedHat, Slackware, Debian, Mandrake, etc), which in terms of what they install and turn on are all much the same.
OTOH hand, this goes deeper than simply what functions are available in a default install. Its a whole design philosophy, which goes beyond what an admin can control. The GNU tools and the Linux kernel (if you build the whole thing, as most distros come just now) have a *lot* of functionality in them, as do many of the server demons commonly used with Linux. OpenBSD have generally resisted the inclusion of new features in the kernel, utilities and networking demons, preferring to restrict themselves to the existing, thoroughly audited and well understood code base.
Alternatively, you can do essentially the same thing, but rather than simply extending actions of the old instructions the new specifier could activate a whole new set of 64-bit instructions, preferably with a saner design.
As an aside, the x86 is not especially hard to write assembly for compared with heavily pipelined RISC and VLIW (or EPIC, if you insist) chips. The instruction set may be crufy, but it doesn't require youy to think like a compiler. Writing compilers, of course, is another matter - compilers for RISC devices are generally much easier to write.
OpenBSD installs are secure by default, whereas most other OSes (including Linux) aim to be featureful by default. Thus there is less scope with OpenBSD for admins to accidentally enable services they don't understand or which contain security flaws. Admins prefer it that way, and part of being a good admin is knowing when this is likely to be a good idea. This approach is better than relying on the admin (even where that is yourself) to reconfigure the machine into a secure setup which is error prone and takes time.
Even a "crappy" admin who installs a vanilla OpenBSD is in a better position than one who installs a vanilla Linux, since lots of work has been doen for them.
Similarly OpenBSD code is audited for security in a fairly formal way, and this is very valuable. Far too much code in standard Linux and *BSD distributions still has simple secutrity flaws like buffere overuns (though it is improving).
I agree. The overall quality of the comments here has been appalling. Many posters seem to be jumping in quick to get Karma without bothering to read the article, let along the (grossly incomplete, actually) language reference.
Part of the problem no doubt is that many/. readers are morons, but part of the problem also is the moderation system - moderators generally only seem to read the first few posts, and usually concentrate on newer articles since those are the ones people read. Maybe the moderation system should be modified to only allow moderation on stories more than X hours old ?
I'm not convinced about making properties and "indexers" part of language, especially the latter since iterators seem more elegant to me than bare integer indices. The main problem in general is the same as that with operator overloading - you cannot tell by reading the source for the client application whether you're calling user code or getting the default behaviour. Bad programmers may introduce complexity by creating indexers etc with side effects. Foreach is a nice idea, but relies on the indexers. All in all this stuff seems to make the language complex for dubious benefit.
The same can be said for user defined value types and box and unbox. I approve of putting the value types into the type hierarchy, but I don't much like the way they've done it. The boxing and unboxing conversions are visible to the developer, whereas in (say) smalltalk integers are implicity always also objects, with no conversion required. The C# system does not allow you to subclass the value types to introduce new numeric representations, and presumably you can't do things like this:
numeric x = 3; numeric y = 3.0; numeric z = x * y;
Where numeric is the common superclass of int and float (in C# there appears to be no such thing, but there could be, and such a system would be better). The important point being that the value types are still not fully objects, they're just easily converted into objects - the only improvement over Java is syntactic (though for most people that may be enough).
In general C# is Java with some gratuitous changes, some of which pull features which are merely conventions in Java into the language, and some of which are additions from VB and C++. Presumably the point is to prevent VB and C++ developers from going over to Java due to its improved developer productivity (which some Windows only people have been doing), by providing a similar language which is more familar to these developers - thus keeping them on the Windows platform. I'm not actually sure C# is simple enough to get the development time gains that Java gets, but its only the perception that really matters.
ILOVEYOU is run automatically just by selectinh the message if you have a particular set of outlook settings - something to do with the . Otherwise it requires the user to run it.
I'm not exactly sure how it works, but MS seem to have added two new statements (over Java) to allow the use of pointers. Methods can be declared unsafe, which propogates through the program, and declares that they may contain code that has pointer errors.
You can also declare pointers within a fixed block. The syntax and semantics for this are not properly defined anywhere, but it seems that it causes the objects pointed to to be fixed in memory so they cannot be moved by the GC. Quite what happens if you move the pointer to another object, I don't know. The simple and stupid implementation would be to have all objects referenced from a fixed block frozen regardless.
The post above has some interesting points, but the list of new features does not match what I read in the lnaguage reference:
- Pass by reference is not explicit. Its the way all instances of classes are passed. Structs and other value types are passed by value. This the main difference between struct and class.
- It seems to initialise variables to default values, like Java.
- Primitive types (and other value types) are kind-of-objects. They are included in the class heierarchy and can be assigned to variables of type object, but this is done using a 'boxing' conversion, which changes the representation, and is not invisible to the developer (as it is in Smalltalk). I don't know whether they have their own class hierarchy - which would make the feature more useful.
Slashdot Mirror
But a lot of [anti-privacy sentiment] comes from people who seem to genuinely believe that basic human rights are a threat to their security or to corporate profits
Well, speaking as someone who has occasionally expressed anti-privacy sentiment, my interest is not in my security or in corporate profits, but in whether or not privacy is a basic human right as you affirm.
There a strong feeling here on /. and elsewhere in the online community that privacy somehow is a fundamental right. This feeling is somewhat libertarian in nature, but interesting there's no libertarian philosophical literature that I can find that takes this position. Indeed, the politicians closest to holding this view are the sopping wet liberal bureaucrats of the European Commission.
The effects of increased and decreased privacy are quite complex, and since this is essentially a proposed addition (or corollary, or whatever) of the historically fundamental human rights, its worthy of more consideration than the knee-jerk reaction it generally gets.
Most of the concern appears to be around privacy from the state apparatus, on the implicit assumption that this provides protection from the enforcement of unjust laws. Its a remarkably weak and at the same time indiscriminate form of protection however.
On the one hand, privacy protections as a defence against law enforcement will inevitably result in an arms race where the state uses improved technology and enhanced legal powers to enforce its laws, and those trying to escape them try to invent more are more powerful protections to their privacy.
On the other hand privacy protections that protect those trying to form political parties, run cooperative enterprises, or trade MP3s will innevitably also protect those who really are international terrorists, theives and child pornographers.
The government will always be able to use the argument that it needs new powers to combat the evil of the day. Joe Bloggs and John Doe will believe them, and to some limited extent, they'll be right. Unfortunately, of course, the state can also use its powers to enforce laws that are not just.
This isn't a battle I want to fight, because I don't think we can win, and the reasons for fighting are weak at best. I think privacy's fundamentally not the issue. Restricting the state to its proper bounds is the issue, and privacy is a poor second best, surrounded by unintended consequences.
They didn't. At this point - if you go an check the usenet flamewar that errupted on this topic - its pretty clear that Telecom NZ (ORBS ISP) accidentally routed ORBS traffic to above.net, which was binning it (as was there right).
Having trawled through everything that was posted on kuro5hin and the usenet posts on this subject, it seems that:
1. MAPS did indeed blackhole ORBS, but opinions seem to differ on whether it has stopped. ORBS is in the habit or testing random relays without asking permission or having evidence of their use for spamming. Rumour keep arising that ORBS also trawls IP-space looks for relays, and that it is impossible to get them to stop testing you, even if you ask (which gets you put on their static list of sites that refuse to be tested). The MAPS guys consider this to be net abuse.
2. Other than ORBS, everyone involved denies that above.net falsely advertised routes for ORBS traffic. Paul Vixie seems to think the misperception (or alternatively the maliciously false accusation) arose because Telecom NZ (ORBS service provider) chose the wrong way of routing ORBS traffic around above.net. Above.net have, however, blocked ORBS traffic in their own network, which they have a perfect right to do.
There were a couple of truly offensive posts (I'm not linking them because I don't think the person who wrote them deserves the publicity) going on about how /. had sold out and was censoring news, and managing to get some racism in there at the same time, posted in two stories including this one. I mailed rusty. I expect he'll zap them.
/. haters are only a tiny minority on kuro5hin and their stories rarely make it to the main page.
/. is news-focussed I think it is quite appropriate for stories to appear on k5 while they are still rumour, but not make it to /. till the fog has cleared. I personally which michael had waited till /. could be authoritative.
/. has not interesting in rubbishing k5, thats just paranoia. k5 is tiny in comparison, and in my view really *shouldn't* grow to /.'s size.
Thats probably what prompted michael to mention it. In general the
Since kuro5hin is discussion-focussed and
Clearly
Yeah, you're right. Although he takes a very long time getting around to it, the parent post seems to be well confused about what constitutes a functional programming language. The author seems to thing they're equivalent to push-down automata (finite state machines with stacks, OK?), but this Just Ain't So.
The source of the confusion seems to be that he assumes functional programming languages are just fixed trees of recursing function calls. If this were so, he'd be right. They aren't, though.
Functional programming languages allow functions to be passed around as values, and these have full first-class status - so you have functions that take functions (which can do loops, or if-then-else constructions), and functions that return functions, which can do all kinds of funky stuff, including, importantly, functions that return a function that does the same thing, but with one parameters already set.
This seems to be what the author is getting at in his blather about "stream programming" and "deferred execution". Its not just a hack, though. Its the very heart of the lambda calculus - its how, in fact, you derive arithmetic from simple functions alone.
*However* the author is clearly a clever chap, and has obviously come up with all this stuff himself, so I say let him keep his mod points. Original thought should be encouraged - even when its wrong.
MacOS X is written on top of Darwin, which is Mach with a BSD-like personality layer on top of it. I heard someone was working on getting an X server working.
The point being that, while MacOS X software will not work on Unix, Unix software should work on MacOS as well as it works on Unix.
High performance != numerics. The authors of the paper you linked are interested in highly accurate floating point processing, something which is pretty rare. I'm unaware of anyone ever arguing that this was an appropriate use of the Java environment.
Similarly the paper you linked that "debunked" the WORA "myth" didn't. It just said it had been debunked. Server-side Java's WORA promise holds good (from wide personal experience, and industrial usage), client-side it is much easier to break *but* can still work.
JIT compilers can at times optimise better than ordinary compilers. For instance, they can perform data-dependent optimisations based on the data arriving during this particular run. OTOH (at least in Java) they can't perform optimisations that need lots of static type information as most of this has been lost. I don't consider the case proven either way.
Oh, and Java is "standardised" by Sun. While I agree that a language controlled by a commercial entity is unusual and potentially harmful its plain silly to make arguments about what "might happen when Java is standardised" as noone with clout has any incentive to push for this to happen.
Don't SHOUT, for goodness sake. We can hear you perfectly well. The most important clue to get here is that the developing world is more than one place - it is not all the same, it contains most of the world's people, and most parts of it are neither dangerous nor starving.
Because of the diversity of circumstances in developing countries, different things are appropriate to different people. Just the same applies in the west - in your case a lesson in elementary geography would probably help most, whereas to a teenage gang member in the south bronx, it would be largely irrelevant.
In the same way, there are people in many parts of the developing world whose biggest obstacles to improving themselves are lack of access to communications technology and education. These tend to be people whose elementary needs for food and moderately stable governance are taken care of, but who are excluded from the process of development by distance or by social and economic forces. Some Amerind tribes throughout the Americas fit this bill, as do some people in India and the stabler parts of Africa.
On the other hand, for the people who fit the stereotyped image of third-worlders, and are either starving or in fear for their lives from bandits, terrorists, geurillas or governments (it can be hard to distinguish), teaching then about Linux would indeed be inappropriate.
Nice troll. Two responses already. Perhaps not quite believable enough. 7/10.
How does a comment which does nothing but reiterate part of the story get moderated up to +4 ?
You're confusing the protocol WAP with the markup language WML. Most of the criticism in the story is about WAP, though there are also problems with WML. Given that Japanese DoCoMo mobiles can already present limited HTML content meaningfully, and have bigger screens and much better market penetration than WML phones anywhere, it seems to be that no good justification exists for WML's pandering to small screen size and assumptions about presentation. Location based services, and web pages integration phone functionality sound like things that could be integrated into the existing scheme of URLs and emphatically don't require a redesign from scratch of the whole protocol suite and a brand new markup language.
As the IETF paper points out, WAP itself (as opposed to WML) seems primarily to be marketing construct rather than a protocol with any significan technical benefits. It especially concerns me that some mobile phone operators will probably use the protocol diconnect between their own services and the real internet to act as "portals" and try to promote a closed content model rather than the traditionally open one of the internet.
No, there is no real native mode. The different CPUs have different VLIW instruction sets.
If by "interpreter" you mean the native firmware that translates the target instruction set into native code (which isn't an interpreter, its a runtime compiler), then there is none for anything other than x86 code. The article you linked doesn't mention anything other than an x86 emulation, and there have been several hints that it would be quite hard.
You can't (obviously) take legal action in Sealand, and for the sake of argument we can assume their security is good enough that you can't take any kind of technical action, however my *point*, which seems to have missed you, was that (as the interviewee says) clients of HavenCo are still liable for their actions in their place of residence of country of citizenship.
In addition HavenCo itself of necessity has (or will have) legal and technical presences outside sealand, which will, depending on jurisdiction, be liable for legal and action, and to have information supeonaed from them. While they're bound to try to prevent this, its not at all obvious to me that they'll succeed.
They're not in international waters. Sealand is entirely surrounded by UK territorial waters no these extend to the 12 mile international limit. Sealand is either UK territory, in which case the inhabitants have the right to due process under UK law, or it a sovereign nation, in which case they can do their own thing.
Personally I think their claim to sovereignty is pretty solid, but I can think of plenty of situations where the UK or someone with tacit cooperation from the UK government (to get access to Sealand through UK territorial waters) would choose to brazen it out. From what Ryan says, it looks like they're going to try and avoid provoking anyone too much (for instance, he stresses legal liabiltiy in people's own jurisdictions), and this makes me feel happier about the whole venture than I did before.
Get a new credit card, I guess, but probably also try to find the person who owns the site. That might be doable throught whois, but more likely would require legal investigation. While HavenCo is probably registered in Anguilla, their peering agreements in the US might make some technical/legal action possible.
I've never seen a Linux distro as well locked down as OpenBSD. If you know of one, please let me know. When I refer to "Vanilla" Linux, I mean one of the more-or-less standard distributions (RedHat, Slackware, Debian, Mandrake, etc), which in terms of what they install and turn on are all much the same.
OTOH hand, this goes deeper than simply what functions are available in a default install. Its a whole design philosophy, which goes beyond what an admin can control. The GNU tools and the Linux kernel (if you build the whole thing, as most distros come just now) have a *lot* of functionality in them, as do many of the server demons commonly used with Linux. OpenBSD have generally resisted the inclusion of new features in the kernel, utilities and networking demons, preferring to restrict themselves to the existing, thoroughly audited and well understood code base.
Alternatively, you can do essentially the same thing, but rather than simply extending actions of the old instructions the new specifier could activate a whole new set of 64-bit instructions, preferably with a saner design.
As an aside, the x86 is not especially hard to write assembly for compared with heavily pipelined RISC and VLIW (or EPIC, if you insist) chips. The instruction set may be crufy, but it doesn't require youy to think like a compiler. Writing compilers, of course, is another matter - compilers for RISC devices are generally much easier to write.
OpenBSD installs are secure by default, whereas most other OSes (including Linux) aim to be featureful by default. Thus there is less scope with OpenBSD for admins to accidentally enable services they don't understand or which contain security flaws. Admins prefer it that way, and part of being a good admin is knowing when this is likely to be a good idea. This approach is better than relying on the admin (even where that is yourself) to reconfigure the machine into a secure setup which is error prone and takes time.
Even a "crappy" admin who installs a vanilla OpenBSD is in a better position than one who installs a vanilla Linux, since lots of work has been doen for them.
Similarly OpenBSD code is audited for security in a fairly formal way, and this is very valuable. Far too much code in standard Linux and *BSD distributions still has simple secutrity flaws like buffere overuns (though it is improving).
I agree. The overall quality of the comments here has been appalling. Many posters seem to be jumping in quick to get Karma without bothering to read the article, let along the (grossly incomplete, actually) language reference.
/. readers are morons, but part of the problem also is the moderation system - moderators generally only seem to read the first few posts, and usually concentrate on newer articles since those are the ones people read. Maybe the moderation system should be modified to only allow moderation on stories more than X hours old ?
Part of the problem no doubt is that many
I'm not convinced about making properties and "indexers" part of language, especially the latter since iterators seem more elegant to me than bare integer indices. The main problem in general is the same as that with operator overloading - you cannot tell by reading the source for the client application whether you're calling user code or getting the default behaviour. Bad programmers may introduce complexity by creating indexers etc with side effects. Foreach is a nice idea, but relies on the indexers. All in all this stuff seems to make the language complex for dubious benefit.
The same can be said for user defined value types and box and unbox. I approve of putting the value types into the type hierarchy, but I don't much like the way they've done it. The boxing and unboxing conversions are visible to the developer, whereas in (say) smalltalk integers are implicity always also objects, with no conversion required. The C# system does not allow you to subclass the value types to introduce new numeric representations, and presumably you can't do things like this:
numeric x = 3;
numeric y = 3.0;
numeric z = x * y;
Where numeric is the common superclass of int and float (in C# there appears to be no such thing, but there could be, and such a system would be better). The important point being that the value types are still not fully objects, they're just easily converted into objects - the only improvement over Java is syntactic (though for most people that may be enough).
In general C# is Java with some gratuitous changes, some of which pull features which are merely conventions in Java into the language, and some of which are additions from VB and C++. Presumably the point is to prevent VB and C++ developers from going over to Java due to its improved developer productivity (which some Windows only people have been doing), by providing a similar language which is more familar to these developers - thus keeping them on the Windows platform. I'm not actually sure C# is simple enough to get the development time gains that Java gets, but its only the perception that really matters.
ILOVEYOU is run automatically just by selectinh the message if you have a particular set of outlook settings - something to do with the . Otherwise it requires the user to run it.
I'm not exactly sure how it works, but MS seem to have added two new statements (over Java) to allow the use of pointers. Methods can be declared unsafe, which propogates through the program, and declares that they may contain code that has pointer errors.
You can also declare pointers within a fixed block. The syntax and semantics for this are not properly defined anywhere, but it seems that it causes the objects pointed to to be fixed in memory so they cannot be moved by the GC. Quite what happens if you move the pointer to another object, I don't know. The simple and stupid implementation would be to have all objects referenced from a fixed block frozen regardless.
The post above has some interesting points, but the list of new features does not match what I read in the lnaguage reference:
- Pass by reference is not explicit. Its the way all instances of classes are passed. Structs and other value types are passed by value. This the main difference between struct and class.
- It seems to initialise variables to default values, like Java.
- Primitive types (and other value types) are kind-of-objects. They are included in the class heierarchy and can be assigned to variables of type object, but this is done using a 'boxing' conversion, which changes the representation, and is not invisible to the developer (as it is in Smalltalk). I don't know whether they have their own class hierarchy - which would make the feature more useful.
I don't know for sure, but I think you'll find both GCC and Emacs are larger (in loc) that the Linux kernel.
OS kernels are certainly complex, in terms of concurrency and so on, but they are not particularly large.