It's always been the truth that any computer wanker that has been caught has been careless. It's just that almost all criminals are sometimes careless.
The question is where people gets recruited to be computer wankers. A large amount of these are from the "scene", starting out with just doing it for fun and becoming more criminal with time. By removing the false glamour of the scene, fewer kids will start out as computer wankers, and there will overall be fewer wankers.
Of course there will be some left. However, that will happen no matter what we do. The money spent on securing computer systems is an insurance policy against the costs of a security break. At each point, the question is how this money can be most effectively spent - on social engineering (propaganda, routines, company morale), on technical engineering, or on an actual insurance policies from Lloyds or similar.
Spending it all on the technical side would be wasteful.
The rest of these are irrelevant, because they do not expect to get caught. Really. Even if the people around them are going down in flames, they don't expect to get caught.
About 15 years ago I was in the "hacker" scene (the ones breaking into computers, not the ones creating brilliant software). Getting caught never felt real, and never seemed to feel real for anybody else, either. My friends got busted left and right, yet - they'd always been careless about something, and I felt that *I* wouldn't be careless about that.
There's one other thing that could work: Break up the scene. The people need to be shown as ridicilous. And it needs to seem ridicilous to the people close to the scene.
For the tagging (grafitti) scene, it seems to have worked somewhat well here in Norway to use advertising to give them a new, ridicilous name and image.
I therefore humbly suggest we from now on call those that break into computers "Computer wankers".
Verbose is NOT easy to read. It means that the important parts get obscured by the dribble. The mind holds 7 (+-2) chunks of information; for a beginner, there's no way to know that that (String) needs to be discarded, etc.
Since when does a beginner programmer do systems administration?
Since Unix machines got common among hobbyists.
They want something that can be powerful, and have the ability to take them far beyond simple 'beginner' languages that are often used (Pascal, Turing, VB6) because those are ass crap.
Beginners are not qualified to evaluate how to learn best. I last programmed Pascal in 1991, and Turbo Pascal as of then had some teaching advantages compared to Java (no need for exception declarations, avoid the == vs = problem that's common for beginners, can do objects but isn't forced to). VB6 has the advantage that it's quite good for doing quick integration tasks and getting stuff done - which is what you seem to consider important above. The language itself is crap, so I wouldn't choose it to teach with, though. I have no opinion of Turing - I've never worked with it.
I've taken money for programming in Java, VB6, Pascal, C, C++, Perl, Ruby, and various assembler languages, which makes me feel at least somewhat qualified about those;)
Compiling a small java program takes about 1 second, compiling is irelevant, and there are good free IDE's (such as JCreator or Eclipse) that are very good, and make it graphically oriented. They even have templates for new simple java programs.
I said interactive use. You know, like a shell where you write code and have it executed at once? As in Smalltalk or Ruby or Lisp or Scheme or sh?
Java is very english-like.
Excuse me? First of all, this sounds like a halucination (Java has a C-like grammar, with operation reordering compared to english and symbols instead of keywords for a lot of structure), second, it's not at all relevant. We tried out that with Cobol, and it didn't make learning any easier.
Beginners write small programs, that dont need many resources anyways, so all arguments against size of overhead and such is really not that important.
Except when I'm doing embedded systems programming or games, I (almost) don't care about overhead anyway. I care about the stuff that Java has added to support programming-in-the-large - such as static type declarations, declarations of exception signatures, the difference between integral and object data types (done for performance), etc.
Plus, Java is the only language to be used for the AP courses that US universities offer.
Yeah, that's a tangiable downside. It means that they end up learning one instead of several languages. All programmers should know at least 4-5 languages, to get more ways of thinking about problems.
I think your syntax evaluations are, basically, wrong. Actually, I think choosing something with a somewhat different syntax is specifically a good idea, to avoid new origranns going into the trap of thinking they can't switch to languages with a differnt style syntax. If they don't get used to switching syntaxes, how are they going to learn SQL, TeX, VB, shell/monad scripting, or functional languages?
And Ruby/Python really have quite conventional syntaxes - there's some small details that differ - primarily, whether {};, keywords, or whitespace is used for statement blocking and termination.
Also, calling Perl's syntax "decent" and protesting against Python/Ruby shows that you do not program Perl, Python, or Ruby much - and as a such should not comment. The perl syntax commonly includes things like @{$wrapdata->[@{$pagelines[$page]}]} and is basically insane; it's a result of the bolt-on nature of perl development. This even carry into using a hack to pass parameters to functions.
My experience with using C to teach beginners was that C was quite difficult to teach, compared to Basic/assembler/Pascal. C++ would have the same problems, and add an arsenal of new and interesting foot-shooting devices (e.g, references, which regularly I see programmers with years of experience abuse, making it necessary to memorize every function/method signature in the program to be able read code reliably).
My opinion is that C is a very good second language, and C++ is probably a good fourth or fifth programming language.
I like C a lot. It's my second favourite language.
However, I've tried teaching beginners using C. It didn't work all; types, pointers, messy output syntax, etc came up too quickly.
I've found it easier to teach non-programmer assembler/machine code than to teach them C. C is easy to teach to somebody that already know programming (in just about any language), though.
I believe Java has serious challenges as a beginner's language.
There's a lot of conceptual baggage. Examples: "You need a class to hold main", "you need a special operator new" (as opposed to a class method), "Classes aren't objects" (why not?), some variables aren't objects (they're ints and friends), etc.
Java requires type declarations, including exceptions declarations. This means that the type system has to be introduced very early, and understanding of exceptions has to be introduced early.
Java needs compiling, and thus gets a slower development cycle. There's (as far as I know) no Java shell where you can play with Java interactively. And even if there is, Java is generally so verbose I think that would be practically useless.
Java is single model. There's only object-oriented code. Yet, beginners' code should usually be linear (do this, do that), then introduce conditions, and then (probably) introduce procedures/functions for organising code, then build methods on top of the basic concept of procedures. In Java, that's all wrapped up in extra conceptual baggage, as Java forces you to declare classes everywhere.
You want to work with containers (collections)? You have to mess about with types and typecasts.
Java is VERBOSE, making it hard to read. As an experiment, I converted a Java 2 Collection example to Ruby. The example contained 518 bytes of variables names, comments, and constant string data. To this, Ruby added 273 bytes of "overhead", landing at 791 bytes. Java had 972 bytes overhead, landing at 1490. In other words, excluding the parts that had to be there, the Java code was 3.5 times larger than the ruby code - in other words, 3.5 times as much clutter.
Java isn't too hot at doing the things that is simplest to do real stuff with quickly: Text processing and systems administration.
"Runnable on any platform" is irrelevant for a beginner. It's also only true for restricted values of 'true'.
"Enterprise level" is irrelevant for a beginner, and nobody should (in my opinion) be doing enterprise programming before they know at least four or five languages.
Note that I believe Java to be a very good choice for large scale development. I just think it's inappropriate for beginners.
Yeah, it does, or at least did. The normal cycle for consoles is subsidy for the first year or so and then very slight profit per console, making the rest up in games.
However, knowing myself and my friends: Without the hardware it's much easier to avoid the temptation of buying, being given as gifts, or pirating those games;)
Why can't people just play the XBox instead of hacking it? I mean seriously, you don't see me hacking my XBox. I buy a game, I play a game. It is quite simple. [...] If they had three freaking bugs, whoopy do. At least I am not the unscrupulous individual who is taking the time and effort into doing something that is morally wrong.
That's debatable. By buying XBox games, you're giving financial support a convicted monopolist. To me, there are some moral issues with that. I resolve them by using neither the XBox nor other Microsoft products[1].
Eivind.
[1] Exception: An inherited Windows PC at work. It runs putty, Firefox, Acrobat Reader, Eudora and Open Office. I see no point in doing a reinstall for a box that works and where the license has already been paid.
I think that would mean that specifying it to the database would be about the same as programming it. You'll need to do a series of invariant specifications at various levels to search by, and these rapidly becomes almost as precise as a program.
The problem is that a lot of the questions we have are somewhat fuzzy. Which is why I think just searching through the database will often be more expensive than implementing something.
I'll use some examples here:
- I worked on implementing a system for being able to write UML diagrams as readable text so I could version control them and look at diffs. The generated diagram had to be laid out automatically "so it looked pretty".
Describing "looked pretty" as invariants is pretty useless. If I knew the invariants, I could as well have coded it.
OK, other example: I wanted to separate concerns in an application for easier testing, so I wanted an Inversion of Control container. Jamis Buck had written a large and complex one called Copland. Now, I had some experience with the concept, but I had no experience with what an IoC framework would give me. I could easily write one by just passing anonymous functions (lambda, procs) around. This would definately be different from what Copland does, and it would take me an hour or three to implement. Now, I spent time to try to understand Copland, to see if the extra complexity there was actually worth anything in my kind of contexts.
In the end, Jamis ended up implementing a separate, simpler IoC framework - and I think using less time on the first implementation of that than I used to look at his previous framework, *even with complete docs and the author available to help me understand the concepts*.
For things that are purely algorithm implementations, searching by specification would probably be useful. Examples of these that I've come across recently:
- Code to compute space-filling grid alignments (a la HTML tables) using minimum sizes and infinities. I worked on this yesterday, and it is fairly standard, fairly easy to produce invariants for, and somewhat hairy to program.
- The stuff I work on right now, which is placement of said boxes, with some wraparound rules if they don't fit, and some speciality rules for section. This is quite fiddly to program in an imperative fashion, and probably too expensive if I do it functionally in a language that doesn't handle that well. Invariants are easy to spec, the code is fiddly. However, an invariant set for this (a spec) should be "trivially" translatable to code by a compiler, anyway, and I doubt anybody has programmed anything JUST like it. Maybe a library that could be used somehow, but I have no idea of what invariants that would have...
- A generic caching system that I wrote for use with objects that were purely specified by their arguments inside my type system for Ruby. Basically, the flyweight pattern. I'm sure somebody else must have implemented that, too, and it is well enough specified that I could use it. However, again this is trivial to code.
My attack on the reuse problems are different than these.
My experience is that libraries come in fairly large packages (no matter how small they are), and that it takes time to learn how to use them. No matter what they are, different programmers would normally do the API and invariants around them slightly different.
Because of the size and "foreignness" of libraries/frameworks, it takes some time to start using a framework, and you do not find out if this framework fit you or not until you've tried it for a while.
The first step you need is a birds-eye view of what packages are available to do what tasks, including subjective views from people about what they like and don't like and why. You can find a start for this for RPA at http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packag eAdvisor
The second step you need is to learn that package. We're trying to move packages to standard documentation, standard codest
I used to think we could do everything through reuse.
My present conclusion is that we will always implement things, and some of them will always be non-trivial. The cost of *finding out if a solution fit the problem* is often so high that it's cheaper to just do it from scratch - and *know* that the solution fit the problem, and that there won't be introduced new problems due to people doing changes elsewhere, and that the code will follow the local coding standards and documentation standards and - for at least a while - have a person locally that have written the code and knows how to change it.
Of course, we can and should try to make software easier to reuse, easier to evaluate whether to reuse, etc. There's a lot of benefit to be had there. You can see some work that I've been involved in that area at http://rubyarchive.org/
Yet - I think we will perpertually have to deal with local code often being cheaper than using external code - even when there exists code that does the same thing.
but unfortunately it allows people to not 'share back' the stuff they took and improved.
... and fortunately this is completely irrelevant except to your feelings.
I'm a FreeBSD developer.
We do get stuff back from many of the commercial derivates, because it's beneficial for all parties (including the people that's done the commercial derivates). It helps merges, and most often the code that commercials write is because they need the functionality for something, and that functionality isn't the core of their product, so they give it back.
For example, our entire SCSI subsystem came from a company producing embedded video hardware.
You know what would have happened if they didn't have the freedom to keep some of the changes proprietary? They'd have licensed something like vxWorks, and FreeBSD would get nothing.
Companies only do work when they see a profit in doing the work, either in the form of decreasing work, community goodwill, increased hardware sales, happier employees, or whatever.
Thus, those that "take FreeBSD and keep their changes proprietary" would otherwise not have made those changes. We've not lost anything. The world has gained, become richer. And, most often, parts of these changes come back to FreeBSD - or some of the developers of them do other changes that come back - so we gain directly from them.
From what I've seen of it, the upgrade system of Debian is better than FreeBSD's. And I say that after having written (small) parts of the FreeBSD upgrade system.
There are other advantages to FreeBSDs methods - safe, reproducable builds, full version history, repeated tests of sets of code togher, easy upgrade of *hacked* code, etc - but the plain upgrades for ports are IMO not quite as good as Debian's.
I've worked with systems that include info for over ten years now. I still can't get used to it; the info browser (/usr/bin/info) is immensely clumsy, and the use of texinfo tend to make the man page a second thought, making the entire documentation set extremely annoying.
My conclusion is that texinfo never grew up, and that the niche it tried to fill has been taken by docbook.
Docbook has one significant technological advantage over texinfo: The omission of a standard command line interface to replace man(1). If you're going to use docbook to maintain documentation that's to be available from the command line - it comes as man pages.
Restricting mountpoint information sounds useful and should be fairly easy to implement. I should probably fix that.
As for spectator context: I cannot remember ever having had a problem with jails and killall -HUP or similar. This might be because I hardly ever use killall, instead using ndc, apachectl, and friends. If there's no control program, I usually look up the PID by ps and grep, unless I really want to kill everything of something - and usually I do that something like
instead of using killall. It's an old habit - find out what I kill before I do it. The clumsy grep | awk comes from reviewing the list before running the kill.
Given this, I think I prefer the way FreeBSD handle this. I think implementing a spectator context should be easy, though, so maybe a kernel tunable to make the "real" server see only the processes started there might be useful.
Is the spectator context more convenient to work with than the FreeBSD method ("host" sees all processes, while the jails only see their own)? Immediately, it sounds less convenient - for instance, it makes just throwing in a jail() call for a single process to throw away privileges *hide* the process from "normal use". I've not lived with vservers, though - is it convenient in practice?
FreeBSD doesn't have SysV IPC virtualization (unless our architecture docs are out of date - I didn't check the most recent code.)
Being able to set up the various forms of limits sounds useful - it's something I've occasionally missed in FreeBSD.
As for filesystem namespaces: Isn't that just union mounts over an image? We've had union mounts for ever, and the union filesystem should work now, as far as I know.
I personally think that hypervisors are overhyped (pun fun!), and that the most practical and useful form of "virtualization" is actually separation as is achieved by Solaris Zones, FreeBSD jails and (the most advanced of them all IMO) Linux Vservers.
What's the extra capabilities of Linux Vservers compared to FreeBSD jails? I couldn't find anything by a quick persual of the vserver Wiki, though that may just be my reading skills acting up as usual;)
The service in other sects (non-Mormon) are different. In the protestant church, there is a sermon by the priest included as part of the rituals. A sermon could include discussion about abuses in the name of christianity, and still be a good sermon (worth listening to.)
I'm no longer a christian, so I don't listen to sermons much anymore, and thus can't say if demoting abuses is common or not. The "christian fringe" situation here in Norway is fairly calm, anyway. For instance, the worst I can remember happening around abortion protests are a couple of
fringe priests bringing out a doll in public and spraying it with ketchup...
erm... What would be the point of OSS then?
(As a reply to the concept of "Paying people to hold a fork for you")
A lot!
From my point of view, the idea of open source is to create value for society. By using open source, we create a richer society - a society with more resources (whether these be people-time or functionality or widgets).
In the example given, it was suggested Apple fork Apache and add a suitable configuration system to it. In some of the statements below, I'm assuming this is done as some form of proprietary product based on Apache - though much of it applies to any form of fork.
So, what's the win of using open source here?
Apple wins by
Not having to maintain the primary webserver code, instead being able to leverage Apache's updates
Getting a known-good codebase, including having heavy testing against all the weird configurations that happen "in the wild", instead of having to go through all the "child problems" with their own codebase
Possibly faster time-to-market (depending on how much of the functionality in Apache they actually will support, how much time their engineers spend in learning the codebase compared to writing something from scratch, etc)
Apache wins by
Getting back the "minor" fixes that Apple does, the ones that haven't got anything to do with Apple's strategic development: The configuration UI. From my experience with doing similar development, this is between 90% and 95% of the time spent on the codebase. These will be contributed back depending on amount of work to give them away, as sharing them makes updating the core codebase much easier.
Even more name recognition
More people that know the Apache codebase, and at some point might hack on it as a hobby
All points under "The general public gets"
The user of the modified web server gets:
A product that's been tested in more configurations, and thus is more likely to work
Possibly a cheaper product (as part of the development cost has already been sunk)
Access to a product that do have those parts that nobody did develop unless paid for it
Possibly a product available at an earlier point in time
All points under "The general public gets"
The general public gets:
A higher quality server less likely to screw up when they connect to it
A higher quality server less likely to screw up the rest of the net somehow
The benefit of of the resources saved from Apple and the users of the webserver, leading to resources availble for doing other things.
Of course, if Apple couldn't use the Apache codebase to do this from, there's a few other possibilities:
Apple does not produce any product (thus all benefits above vanish into thin air)
Apple produce a product from scratch (thus the user gets his product, but Apache gets nothing)
Apple license another codebase somehow (either using another open source codebase or doing commercial licensing)
Eh - that's the medium size picture. In the even bigger picture, "security" is there for a purpose. In a commercial setting, that purpose is "Making/saving money". For eBay, the perception of "A lot of people get all their stuff stolen on the Internet and eBay is often involved and my neighbours son says eBay don't care" is, if widespread, catastrophic. In other words: Client side security is quite important for their business.
More generally, the cost of any reasonably broad problem with users' security will fall back on the merchants/banks/companies somehow, and thus are or should be on the radar for any security manager for a large web company that involves money changing hands.
These issues are taken seriously by many of the players in the market. For instance, one company I consulted for scrapped and reimplemented a multimillion dollar system when we demo'ed client security issues that they could not work around in their present system.
Now, it is probably a bad idea for eBay to recommend particular computer desktop setups for security. All the popular systems of today have design issues[1] that make security issues pop up "all the time." However, what happens on the user end definately do matter to them.
Eivind.
[1] There are design issues are both on the user interface level and technical level. For an overview of secure interface design, see Interaction Design for End User Security. The tech level is "everything" running with too many privileges, mostly.
His behaviour was immoral - obviously, it's fairly unlikely that anyone is purposely sharing their wireless network - but not illegal.
Eh?
My impression is that techies in fairly often set their wireless networks open, specifically to allow random people to get access. They prefer to do bandwidth shaping to restrict abusers, if it becomes a problem. That's based on reading discussions all over the place.
At the moment, there's only two tech people that I know and know to have home wireless networks - both of them have left it open on purpose. One of them actually only has the wireless router on to allow his neighbours to connect to the net in a pinch (it's a router he got for free, I think.)
Not that I have a large sample available - "How is your home network configured?" is sort of "The Bore" among conversation starters...
I've programmed in each of these areas (through a past as a commercial games developer) - and I've been heavily involved in open source projects for a long time now.
Open source competing in the area of graphics editing and video editing seems likely. Competiting in the area of games? Much less likely. From a development point of view, today's games are not a programming proposition. Graphics, sound, and story are more work than programming. The development work division are closer to that of movie production than that of traditional application development.
In addition, games generally get "spent". People play them for a while, then throw them away, rather than doing ongoing use of them (and thus ending up fixing things in them). The distance between enjoying playing a game and enjoying fixing things in it is much, much larger than for an application.
There are a lot of amateur movies being produced, and while these can often be fun to watch, calling them "Worthy competition for the Hollywood movies" just isn't true - simply shown by almost everybody choosing to watch mostly Hollywood movies instead of the low budget ones, including the kind of people that *do* know a lot about the amateur films produced.
These things might change over time, of course - media production gets simpler all the time - yet it still seems that gap between professionals and hobbyists is widening instead of tightening.
Eivind.
I'm a FreeBSD developer, and I find the ideas about impact of the BSD license to be different than the reality. In fact, much the reality as I've seen it is almost the opposite of the popular myths.
Companies want to put most of their changes back to the main codebase, and if they see a chance to do so, they will usually go to significant effort to make their code palatable to FreeBSD.
There are sound financial reasons for companies to want to contribute back (goodwill and tech support from the community, internal morale, avoiding the cost of conflicts when they update to a new version of our codebase, etc).
The primary issue we have with contributions are getting *individuals* to contribute. Here, the BSD licensing play a role. Among many of the people in the GPL camp, there is a significant amount of fear of feeling exploited, and people often chose the GPL due to that fear. People also choose the GPL in an idealistic belief that it result in more free code.
Whether this fear is realistic or not and whether the belief is realistic or not are subjects for debate[1]. The reality is that the fear and belief exist and influence developer availability - slightly. (Development infrastructure, code base size, culture, and public perception of "Cathedral" vs "Bazaar" models are much larger influences.)
My ideal open source license would be one that allowed limited time proprietary branching. Say, two years. Then the modifications have to be made public under the same license.
This gives the benefit from the BSD license - the work on the codebase and contributions done by those that make proprietary implementations from it (example: the Whistle Interjet based on FreeBSD, now bought by IBM), giving them time to make a profit - and it ensure that those changes become available to the open source community.
Slashdot Mirror
The question is where people gets recruited to be computer wankers. A large amount of these are from the "scene", starting out with just doing it for fun and becoming more criminal with time. By removing the false glamour of the scene, fewer kids will start out as computer wankers, and there will overall be fewer wankers.
Of course there will be some left. However, that will happen no matter what we do. The money spent on securing computer systems is an insurance policy against the costs of a security break. At each point, the question is how this money can be most effectively spent - on social engineering (propaganda, routines, company morale), on technical engineering, or on an actual insurance policies from Lloyds or similar.
Spending it all on the technical side would be wasteful.
Eivind.
The rest of these are irrelevant, because they do not expect to get caught. Really. Even if the people around them are going down in flames, they don't expect to get caught.
About 15 years ago I was in the "hacker" scene (the ones breaking into computers, not the ones creating brilliant software). Getting caught never felt real, and never seemed to feel real for anybody else, either. My friends got busted left and right, yet - they'd always been careless about something, and I felt that *I* wouldn't be careless about that.
There's one other thing that could work: Break up the scene. The people need to be shown as ridicilous. And it needs to seem ridicilous to the people close to the scene.
For the tagging (grafitti) scene, it seems to have worked somewhat well here in Norway to use advertising to give them a new, ridicilous name and image.
I therefore humbly suggest we from now on call those that break into computers "Computer wankers".
Eivind.
Since when does a beginner programmer do systems administration?
Since Unix machines got common among hobbyists.
They want something that can be powerful, and have the ability to take them far beyond simple 'beginner' languages that are often used (Pascal, Turing, VB6) because those are ass crap.
Beginners are not qualified to evaluate how to learn best. I last programmed Pascal in 1991, and Turbo Pascal as of then had some teaching advantages compared to Java (no need for exception declarations, avoid the == vs = problem that's common for beginners, can do objects but isn't forced to). VB6 has the advantage that it's quite good for doing quick integration tasks and getting stuff done - which is what you seem to consider important above. The language itself is crap, so I wouldn't choose it to teach with, though. I have no opinion of Turing - I've never worked with it.
I've taken money for programming in Java, VB6, Pascal, C, C++, Perl, Ruby, and various assembler languages, which makes me feel at least somewhat qualified about those ;)
Compiling a small java program takes about 1 second, compiling is irelevant, and there are good free IDE's (such as JCreator or Eclipse) that are very good, and make it graphically oriented. They even have templates for new simple java programs.
I said interactive use. You know, like a shell where you write code and have it executed at once? As in Smalltalk or Ruby or Lisp or Scheme or sh?
Java is very english-like.
Excuse me? First of all, this sounds like a halucination (Java has a C-like grammar, with operation reordering compared to english and symbols instead of keywords for a lot of structure), second, it's not at all relevant. We tried out that with Cobol, and it didn't make learning any easier.
Beginners write small programs, that dont need many resources anyways, so all arguments against size of overhead and such is really not that important.
Except when I'm doing embedded systems programming or games, I (almost) don't care about overhead anyway. I care about the stuff that Java has added to support programming-in-the-large - such as static type declarations, declarations of exception signatures, the difference between integral and object data types (done for performance), etc.
Plus, Java is the only language to be used for the AP courses that US universities offer.
Yeah, that's a tangiable downside. It means that they end up learning one instead of several languages. All programmers should know at least 4-5 languages, to get more ways of thinking about problems.
Eivind.
Oh, and not providing access to the Internet would usually be against the ALA library guidelines, goal #1.13.
Oh, and running censorware would be against the ALA Ethics Guidelines, point III.
Eivind.
And Ruby/Python really have quite conventional syntaxes - there's some small details that differ - primarily, whether {};, keywords, or whitespace is used for statement blocking and termination.
Also, calling Perl's syntax "decent" and protesting against Python/Ruby shows that you do not program Perl, Python, or Ruby much - and as a such should not comment. The perl syntax commonly includes things like @{$wrapdata->[@{$pagelines[$page]}]} and is basically insane; it's a result of the bolt-on nature of perl development. This even carry into using a hack to pass parameters to functions.
My experience with using C to teach beginners was that C was quite difficult to teach, compared to Basic/assembler/Pascal. C++ would have the same problems, and add an arsenal of new and interesting foot-shooting devices (e.g, references, which regularly I see programmers with years of experience abuse, making it necessary to memorize every function/method signature in the program to be able read code reliably).
My opinion is that C is a very good second language, and C++ is probably a good fourth or fifth programming language.
Eivind.
I do not know of any (actively used) language that is MORE verbose than Java. Can you name one?
Eivind.
However, I've tried teaching beginners using C. It didn't work all; types, pointers, messy output syntax, etc came up too quickly.
I've found it easier to teach non-programmer assembler/machine code than to teach them C. C is easy to teach to somebody that already know programming (in just about any language), though.
Eivind.
- There's a lot of conceptual baggage. Examples: "You need a class to hold main", "you need a special operator new" (as opposed to a class method), "Classes aren't objects" (why not?), some variables aren't objects (they're ints and friends), etc.
- Java requires type declarations, including exceptions declarations. This means that the type system has to be introduced very early, and understanding of exceptions has to be introduced early.
- Java needs compiling, and thus gets a slower development cycle. There's (as far as I know) no Java shell where you can play with Java interactively. And even if there is, Java is generally so verbose I think that would be practically useless.
- Java is single model. There's only object-oriented code. Yet, beginners' code should usually be linear (do this, do that), then introduce conditions, and then (probably) introduce procedures/functions for organising code, then build methods on top of the basic concept of procedures. In Java, that's all wrapped up in extra conceptual baggage, as Java forces you to declare classes everywhere.
- You want to work with containers (collections)? You have to mess about with types and typecasts.
- Java is VERBOSE, making it hard to read. As an experiment, I converted a Java 2 Collection example to Ruby. The example contained 518 bytes of variables names, comments, and constant string data. To this, Ruby added 273 bytes of "overhead", landing at 791 bytes. Java had 972 bytes overhead, landing at 1490. In other words, excluding the parts that had to be there, the Java code was 3.5 times larger than the ruby code - in other words, 3.5 times as much clutter.
- Java isn't too hot at doing the things that is simplest to do real stuff with quickly: Text processing and systems administration.
"Runnable on any platform" is irrelevant for a beginner. It's also only true for restricted values of 'true'."Enterprise level" is irrelevant for a beginner, and nobody should (in my opinion) be doing enterprise programming before they know at least four or five languages.
Note that I believe Java to be a very good choice for large scale development. I just think it's inappropriate for beginners.
Eivind.
However, knowing myself and my friends: Without the hardware it's much easier to avoid the temptation of buying, being given as gifts, or pirating those games ;)
Eivind.
That's debatable. By buying XBox games, you're giving financial support a convicted monopolist. To me, there are some moral issues with that. I resolve them by using neither the XBox nor other Microsoft products[1].
Eivind.
[1] Exception: An inherited Windows PC at work. It runs putty, Firefox, Acrobat Reader, Eudora and Open Office. I see no point in doing a reinstall for a box that works and where the license has already been paid.
I think that would mean that specifying it to the database would be about the same as programming it. You'll need to do a series of invariant specifications at various levels to search by, and these rapidly becomes almost as precise as a program. The problem is that a lot of the questions we have are somewhat fuzzy. Which is why I think just searching through the database will often be more expensive than implementing something. I'll use some examples here: - I worked on implementing a system for being able to write UML diagrams as readable text so I could version control them and look at diffs. The generated diagram had to be laid out automatically "so it looked pretty". Describing "looked pretty" as invariants is pretty useless. If I knew the invariants, I could as well have coded it. OK, other example: I wanted to separate concerns in an application for easier testing, so I wanted an Inversion of Control container. Jamis Buck had written a large and complex one called Copland. Now, I had some experience with the concept, but I had no experience with what an IoC framework would give me. I could easily write one by just passing anonymous functions (lambda, procs) around. This would definately be different from what Copland does, and it would take me an hour or three to implement. Now, I spent time to try to understand Copland, to see if the extra complexity there was actually worth anything in my kind of contexts. In the end, Jamis ended up implementing a separate, simpler IoC framework - and I think using less time on the first implementation of that than I used to look at his previous framework, *even with complete docs and the author available to help me understand the concepts*. For things that are purely algorithm implementations, searching by specification would probably be useful. Examples of these that I've come across recently: - Code to compute space-filling grid alignments (a la HTML tables) using minimum sizes and infinities. I worked on this yesterday, and it is fairly standard, fairly easy to produce invariants for, and somewhat hairy to program. - The stuff I work on right now, which is placement of said boxes, with some wraparound rules if they don't fit, and some speciality rules for section. This is quite fiddly to program in an imperative fashion, and probably too expensive if I do it functionally in a language that doesn't handle that well. Invariants are easy to spec, the code is fiddly. However, an invariant set for this (a spec) should be "trivially" translatable to code by a compiler, anyway, and I doubt anybody has programmed anything JUST like it. Maybe a library that could be used somehow, but I have no idea of what invariants that would have... - A generic caching system that I wrote for use with objects that were purely specified by their arguments inside my type system for Ruby. Basically, the flyweight pattern. I'm sure somebody else must have implemented that, too, and it is well enough specified that I could use it. However, again this is trivial to code. My attack on the reuse problems are different than these. My experience is that libraries come in fairly large packages (no matter how small they are), and that it takes time to learn how to use them. No matter what they are, different programmers would normally do the API and invariants around them slightly different. Because of the size and "foreignness" of libraries/frameworks, it takes some time to start using a framework, and you do not find out if this framework fit you or not until you've tried it for a while. The first step you need is a birds-eye view of what packages are available to do what tasks, including subjective views from people about what they like and don't like and why. You can find a start for this for RPA at http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packag eAdvisor The second step you need is to learn that package. We're trying to move packages to standard documentation, standard codest
I used to think we could do everything through reuse.
My present conclusion is that we will always implement things, and some of them will always be non-trivial. The cost of *finding out if a solution fit the problem* is often so high that it's cheaper to just do it from scratch - and *know* that the solution fit the problem, and that there won't be introduced new problems due to people doing changes elsewhere, and that the code will follow the local coding standards and documentation standards and - for at least a while - have a person locally that have written the code and knows how to change it.
Of course, we can and should try to make software easier to reuse, easier to evaluate whether to reuse, etc. There's a lot of benefit to be had there. You can see some work that I've been involved in that area at http://rubyarchive.org/
Yet - I think we will perpertually have to deal with local code often being cheaper than using external code - even when there exists code that does the same thing.
Eivind.
I'm a FreeBSD developer.
We do get stuff back from many of the commercial derivates, because it's beneficial for all parties (including the people that's done the commercial derivates). It helps merges, and most often the code that commercials write is because they need the functionality for something, and that functionality isn't the core of their product, so they give it back.
For example, our entire SCSI subsystem came from a company producing embedded video hardware.
You know what would have happened if they didn't have the freedom to keep some of the changes proprietary? They'd have licensed something like vxWorks, and FreeBSD would get nothing.
Companies only do work when they see a profit in doing the work, either in the form of decreasing work, community goodwill, increased hardware sales, happier employees, or whatever.
Thus, those that "take FreeBSD and keep their changes proprietary" would otherwise not have made those changes. We've not lost anything. The world has gained, become richer. And, most often, parts of these changes come back to FreeBSD - or some of the developers of them do other changes that come back - so we gain directly from them.
Eivind.
There are other advantages to FreeBSDs methods - safe, reproducable builds, full version history, repeated tests of sets of code togher, easy upgrade of *hacked* code, etc - but the plain upgrades for ports are IMO not quite as good as Debian's.
Eivind.
My conclusion is that texinfo never grew up, and that the niche it tried to fill has been taken by docbook.
Docbook has one significant technological advantage over texinfo: The omission of a standard command line interface to replace man(1). If you're going to use docbook to maintain documentation that's to be available from the command line - it comes as man pages.
Eivind.
As for spectator context: I cannot remember ever having had a problem with jails and killall -HUP or similar. This might be because I hardly ever use killall, instead using ndc, apachectl, and friends. If there's no control program, I usually look up the PID by ps and grep, unless I really want to kill everything of something - and usually I do that something like
instead of using killall. It's an old habit - find out what I kill before I do it. The clumsy grep | awk comes from reviewing the list before running the kill.Given this, I think I prefer the way FreeBSD handle this. I think implementing a spectator context should be easy, though, so maybe a kernel tunable to make the "real" server see only the processes started there might be useful.
Thank you for the answers, BTW :)
Eivind.
FreeBSD doesn't have SysV IPC virtualization (unless our architecture docs are out of date - I didn't check the most recent code.)
Being able to set up the various forms of limits sounds useful - it's something I've occasionally missed in FreeBSD.
As for filesystem namespaces: Isn't that just union mounts over an image? We've had union mounts for ever, and the union filesystem should work now, as far as I know.
Eivind.
What's the extra capabilities of Linux Vservers compared to FreeBSD jails? I couldn't find anything by a quick persual of the vserver Wiki, though that may just be my reading skills acting up as usual
Eivind.
Good analogy.
I'm no longer a christian, so I don't listen to sermons much anymore, and thus can't say if demoting abuses is common or not. The "christian fringe" situation here in Norway is fairly calm, anyway. For instance, the worst I can remember happening around abortion protests are a couple of fringe priests bringing out a doll in public and spraying it with ketchup...
Eivind.
A lot!
From my point of view, the idea of open source is to create value for society. By using open source, we create a richer society - a society with more resources (whether these be people-time or functionality or widgets).
In the example given, it was suggested Apple fork Apache and add a suitable configuration system to it. In some of the statements below, I'm assuming this is done as some form of proprietary product based on Apache - though much of it applies to any form of fork.
So, what's the win of using open source here?
Apple wins by
- Not having to maintain the primary webserver code, instead being able to leverage Apache's updates
- Getting a known-good codebase, including having heavy testing against all the weird configurations that happen "in the wild", instead of having to go through all the "child problems" with their own codebase
- Possibly faster time-to-market (depending on how much of the functionality in Apache they actually will support, how much time their engineers spend in learning the codebase compared to writing something from scratch, etc)
Apache wins by- Getting back the "minor" fixes that Apple does, the ones that haven't got anything to do with Apple's strategic development: The configuration UI. From my experience with doing similar development, this is between 90% and 95% of the time spent on the codebase. These will be contributed back depending on amount of work to give them away, as sharing them makes updating the core codebase much easier.
- Even more name recognition
- More people that know the Apache codebase, and at some point might hack on it as a hobby
- All points under "The general public gets"
The user of the modified web server gets:- A product that's been tested in more configurations, and thus is more likely to work
- Possibly a cheaper product (as part of the development cost has already been sunk)
- Access to a product that do have those parts that nobody did develop unless paid for it
- Possibly a product available at an earlier point in time
- All points under "The general public gets"
The general public gets:- A higher quality server less likely to screw up when they connect to it
- A higher quality server less likely to screw up the rest of the net somehow
- The benefit of of the resources saved from Apple and the users of the webserver, leading to resources availble for doing other things.
Of course, if Apple couldn't use the Apache codebase to do this from, there's a few other possibilities:Eivind.
More generally, the cost of any reasonably broad problem with users' security will fall back on the merchants/banks/companies somehow, and thus are or should be on the radar for any security manager for a large web company that involves money changing hands.
These issues are taken seriously by many of the players in the market. For instance, one company I consulted for scrapped and reimplemented a multimillion dollar system when we demo'ed client security issues that they could not work around in their present system.
Now, it is probably a bad idea for eBay to recommend particular computer desktop setups for security. All the popular systems of today have design issues[1] that make security issues pop up "all the time." However, what happens on the user end definately do matter to them.
Eivind.
[1] There are design issues are both on the user interface level and technical level. For an overview of secure interface design, see Interaction Design for End User Security. The tech level is "everything" running with too many privileges, mostly.
Eh?
My impression is that techies in fairly often set their wireless networks open, specifically to allow random people to get access. They prefer to do bandwidth shaping to restrict abusers, if it becomes a problem. That's based on reading discussions all over the place.
At the moment, there's only two tech people that I know and know to have home wireless networks - both of them have left it open on purpose. One of them actually only has the wireless router on to allow his neighbours to connect to the net in a pinch (it's a router he got for free, I think.)
Not that I have a large sample available - "How is your home network configured?" is sort of "The Bore" among conversation starters...
Eivind.
I've programmed in each of these areas (through a past as a commercial games developer) - and I've been heavily involved in open source projects for a long time now. Open source competing in the area of graphics editing and video editing seems likely. Competiting in the area of games? Much less likely. From a development point of view, today's games are not a programming proposition. Graphics, sound, and story are more work than programming. The development work division are closer to that of movie production than that of traditional application development. In addition, games generally get "spent". People play them for a while, then throw them away, rather than doing ongoing use of them (and thus ending up fixing things in them). The distance between enjoying playing a game and enjoying fixing things in it is much, much larger than for an application. There are a lot of amateur movies being produced, and while these can often be fun to watch, calling them "Worthy competition for the Hollywood movies" just isn't true - simply shown by almost everybody choosing to watch mostly Hollywood movies instead of the low budget ones, including the kind of people that *do* know a lot about the amateur films produced. These things might change over time, of course - media production gets simpler all the time - yet it still seems that gap between professionals and hobbyists is widening instead of tightening. Eivind.
I'm a FreeBSD developer, and I find the ideas about impact of the BSD license to be different than the reality. In fact, much the reality as I've seen it is almost the opposite of the popular myths.
Companies want to put most of their changes back to the main codebase, and if they see a chance to do so, they will usually go to significant effort to make their code palatable to FreeBSD.
There are sound financial reasons for companies to want to contribute back (goodwill and tech support from the community, internal morale, avoiding the cost of conflicts when they update to a new version of our codebase, etc).
The primary issue we have with contributions are getting *individuals* to contribute. Here, the BSD licensing play a role. Among many of the people in the GPL camp, there is a significant amount of fear of feeling exploited, and people often chose the GPL due to that fear. People also choose the GPL in an idealistic belief that it result in more free code.
Whether this fear is realistic or not and whether the belief is realistic or not are subjects for debate[1]. The reality is that the fear and belief exist and influence developer availability - slightly. (Development infrastructure, code base size, culture, and public perception of "Cathedral" vs "Bazaar" models are much larger influences.)
My ideal open source license would be one that allowed limited time proprietary branching. Say, two years. Then the modifications have to be made public under the same license.
This gives the benefit from the BSD license - the work on the codebase and contributions done by those that make proprietary implementations from it (example: the Whistle Interjet based on FreeBSD, now bought by IBM), giving them time to make a profit - and it ensure that those changes become available to the open source community.
Eivind.