The number one concern of employers is how to retain their employees for more that 6 months due to aggressive recruiting techniques and incentives from competitors.gap.
OK, perhaps you are right, perhaps the current IT market there is healthy. Maybe some people will enjoy a nice job for a while. But the point I'm so trying badly to make;-) is that the odds of it staying like that are stacked against. Things can only get worse. A cheaper country will come along and the Indians will have to force down wages as much as they can, or the companies will just get up and leave "en masse", probably both.
With the constant threat of "going to China", any good times are not going to stay that way for very long.
Nobody is being forced to labour in an IBM sweatshop in India.
And what choice do they have? It's either take the job or be unemployed and have no money food etc, and hope that your familiy can support you. (Welfare? doesn't exist of course)
IBM will have to pay top-dollar in Indian wages in order to attract the best talent.
What makes you think that IBM are even looking for the best talent? Most IT jobs are just boring and don't require geniuses. There will be thousands of people competing against each other for those jobs. That is why IBM wants to go to India. Cheap job market where they can call the shots.
(hence the mad scramble by most Indians to get any possible qualification in IT so they can get on the gravy train.)
And that is exactly why _even_ if it is a gravy train now, it won't stay that way for very long.
How much bargaining power in the job market do you think these Indian workers have?
... and then the poor people of those countries become middle class thus decreasing the variance of the world socioeconomic gap.
If the textile industry is any guide, the people will be paid a starvation wage, until the company finds a cheaper source of labour and moves there, leaving the poor workers once again poor and unemployed.
people in India are getting that health care they've always wanted.
You have got to be kidding.;-D What makes you think there is going to be any extra money for things like health care after IBM or whoever move in and pay as little as possible?
All of this is ignoring things like Free Trade Zones where governments drop taxes (and often human rights) for companies as an incentive for foreign investment...
But if you think about it, putting the syntax directly into the language has some benefits. You can check if a file exists with a single operator. In Python, you have to remember the name of the function *and* which module it is located in, then you have to import that module. This adds up to a lot of extra mental noise.
Which is small price to pay for readable code (and that's assuming that -f and -d, etc is easier to remember than os.path.isfile() and os.path.isdir().) I can't believe that people still think that reducing keystrokes somehow equates to improved programmer effectiveness. It's readability that counts since code is read so much more often than it is written. Hell, even a non-python programmer can read "os.path.isfile()" and guess what it does. I can't say the same about Perl's -f, -d and -e.
...However, it shouldn't be the first thing you do. That's the top-down design paradigm, and it doesn't make for particularily maintainable code...
...Whatever you do, don't code the UI first...
But when you do get to the UI, make sure you have your target audience in mind, take the time to design it for maximum usuability,
You've got interface design all confused and mixed up with interface implementation. They are most definately not the same thing. Interface design should definately happen before code is even written. (Sketched out on paper etc) Interface implementation can happen whenever it makes sense for the programmer. (top-down, bottom-up, sideways, whatever.)
You need to realise that the GUI exists to do what the users wishes, and the core code exists to do what the GUI wishes. It's not a case of the GUI being there to expose the functionality of the 'engine' underneath, and the user having to make do with whatever they are given. The GUI must be designed first. How can you write the engine code without knowing what the GUI/user will need to do?
If you design the GUI after the core code is written you will end up with a design suited to the core 'engine' and not to the user.
It's how the user interfaces with your program, so it's going to be the biggest element in how they judge the usuability and usefulness of your project.
It is not just how the user judges your program, for the user it is the program.
"start with the interface". I mean c'mon. That's not the right way to program...that's just backwards.
:-) I can't help but feel that the traditional wisdom in the software industry about how to develop software, is just damaging programmers. Much like teaching BASIC...
The user interface is the first thing that should be designed when developing a program. Even before any code is written, it should be planned out somehow (pencil and paper is good at this stage). Only once you know what you are trying to make should you start working out how it should work internally to achieve that goal.
The interface is the most important thing. It is what you are building. Everything else flows from that.
Mozilla core isn't either (the front end is, but you could wrap the Gecko API for some other language to create that).
Interesting that you should pick Moz as an example. Because that is basically how it works inside Moz also. Moz is just a big bunch of C++ modules acting as libraries and an application 'runtime', with the higher level application stuff all being written on top using Javascript, XUL etc.
The second link is definately worth reading, and is quite disturbing. IMHO, there is something very very wrong, and it's not just a case of "a few people needing a few drugs".
Hey, give Alston some credit. We laughed when he tried to introduce censorship on the net. But with only 2% of Australian's having broadband and thus the technical capability for downloading and viewing today's porn, I would say that he's done a great job of keeping that nasty porn and gambling away from those poor Aussies.
From the article:
"
It is only in the last year that Alston has come to acknowledge the importance of broadband, having previously dismissed it as primarily a distribution platform for pornography and gambling. As recently as 12 months ago he still maintained that for consumers it was mostly for "entertainment-related" activity such as music and video downloads and thus of dubious value for national productivity. "
Can you clarify your long term goals with respect to ReiserFS and file system design in geek lay man's terms?
I'm refering to your Future Vision paper in particular. How would this kind of system be used on a day to day basis?
Right now any mention here of adding database like functionality to a file system is met with crude comments about SQL... Some explaination would really help.
The only problem is the startup fee. The minimum you can spend to try it out is $45 (three months at $15) - you have to sign up for at least a year to get the $10/month price.
You can do the free trial that they offer (50 free MP3s). Also, I don't know how much CDs cost where you are, but compared to buying CDs, I've paid $45 for three months and have already downloaded 25 albumns (just joined 2 weeks ago). Not to mention that the music I'm after (electonic, industrial) isn't really available in the shops. If emusic have what you want, it's a great deal.
MS has licensed the UNIX source and related IP. They have not bought it from SCO, and they certainly haven't bought the right to "sue everyone that pushes Linux". sheeesh...
Thanks for the tip, but I'm not really asking a question about Social Engineering, although it is an important aspect of security. My point is really that most security software has such bad usability that people can't even use it and hence ignore it or try to work around it. You can have the strongest encryption in the world, but it doesn't matter if it can't be used correctly... Some thing for most security software.
Don't confuse the issue of computer security and usability with the issue of TCPA and 'securing' digital content from customers. By doing so you are being fooled by Microsoft and the media companies.
"Given the choice between dancing pigs and security, users will pick dancing pigs every time." -- Ed Felten
examples:
* "SSH shows a warning that the host key has changed. The user ignores it and continues on."
* "The browser warns the a SSL certificate doesn't match the host IP. The user ignores it and continues on."
* "The browser asks if you trust the signer before running some piece of ActiveX. The user ignores it and continues on."
* "The sysadmin warns not to share passwords. The users ignore that too."
Now the question. It seems to me that despite all the work being done in the security field, back in reality things have gone from bad to worse. People constantly sidestep the very systems that are put in place to protect them. Is anything being done in the computer security field to address this important "Human Factors" aspect?
Can someone running OS X try some of these problems out and see how OS X reacts. How does it treat weird ass accented characters and the like? Is OS X insensitive just for the simple non-accented English characters or what?
Do these problems really exist? are they bad? Can we have some real evidence instead of just opinion.
The number one problem that I had with PHP isn't so much to do with it's OOP support but more to do with it's "pass by value" default, when it comes to function arguments. For small non-OO programs it's not too much of a problem. But when writing OO stuff it's murder because you almost always want to be passing objects around by reference, you don't want copies being made. This, for me, lead to tons of subtle "Why isn't that object getting changed?" type bugs. Having to be explicit about object passing was just totally working against me. That and the "kind of symbol table references" that are not quite like C pointers and are not quite the same as Java/Python references, was very annoying and also lead to bugs.
These problems made simple OO programming a real trial. Maybe you could say "Well Simon, that's just your C/C++/Java bias there", but I just can't imagine the benefit or desire for having "pass by value" by default for objects... I was hoping that PHP would be a good general script language (the library support is excellent), but that was the deal breaker for me.
If you want to get into Python, I would recommend quickly going through the Tutorial on the Python site to get a feel for how it works and what's available, then browse the Library reference to get an idea about what is available there, and then just choose a smallish problem and go solve it. (Refer back when needed.)
This book might be worth checking out too:
http://www.andamooka.org/reader.pl?section=divein
Personally I program with "Python in a Nutshell" by my hand.
I had a hard time keeping track of what was declared and when in Python (because the field will flat out not exist until it is assigned a value). Granted you can have null references in Java; atleast you can be guaranteed the field is actually there. This is just my nitpick with python though
Initialise your fields in the __init__() initialiser. Assign the value 'None' to the "not yet used" fields, just like Java. No more "missing until assigned fields".
This is probably going to sound a bit repeatative, but I was reading your comment and I thought "here is someone looking for Python".
After spending years using Perl for my small ad hoc stuff, I realised that it just plains sucks. Too many basic things were needlessly difficult. I'm referring to things like defining functions, defining classes, defining and using data structures, plus the unreadable line-noise syntax and the 'under the covers' hidden variable stuff.
Anyway, after that started looking and even went through a PHP phase. Hoping to be also able to use it as a general scripting language. That little "fling" ended after I tried writting Object Oriented code in PHP... the pain!....PHP just does not scale.
So finally I got around to trying out Python. I had heard a few very high recommendations about it in the past. Wow! Everything is as simple as possible, meaning you can keep it in your head for quick access, while still being very powerful. After a few days at Python I tried some metaclass hacking, something I would never dream of in Perl, and it just worked, with almost no effort. Couldn't believe it. Everything is just so fast and simple, and it scales too. I can't praise it enough. I think that most application can and should be written in Python these days. It just makes sense. (Python + Qt is just sweeeet.)
"Versions of the same library were always backwards compatible. This was Law."
And that Law is bundled with an entirely new class of problems, and is an obvious deterrent to development progress.
I certainly don't remember hearing anyone complain about it. Seeing the alternative (Windows 3.1 at the time) people quickly realised how much better off we were by doing things this way.
What "new class of problems" are you worried about?
Well, I think that technically Linux probably has everything neccessary already. It's really a policy issue. I just browsed the Program Library HOWTO, and although binary compatibility is briefly mentioned, and what is meant to happen when you break it. The whole idea that libraries have APIs that should only be broken as a last resort, is simply not explained, let alone handed down as Law...
That's not to say that things are not changing. The KDE project for example, aims for maintaining binary compatability during the same major series. Also Mandrake at least, now seem to understand that different major numbers should indicate different libraries. Which is why most of library packages now have the major number in thier names (eg libpcap0, libpng3). Idea being that you can install different versions side by side if needed.
But there are still problems. For example, RPM, when building a package likes to list the library dependancies for the software in the package, but also the libraries that that libraries depend on. (Which is why sometimes you see packages with a dependancy on libopenGL.x or so. That lib is not on most people's machines. It's a case of RPM picking up a dependancy on part of the nVidia drivers installed on the build machine.) You code to the interface, not the implementation!
(IIRC, windows has DLL versioning too. It's optional (!) and of course no-one bothered to use it... sometimes laws have to made.)
Just want point out that problems with shared libraries aren't universal. Years ago AmigaOS had shared libraries that basically worked without significant administration problems, or a 'dll hell'.
Important features of the way AmigaOS libraries worked:
* All libraries were versioned, but not on the file system level. Each library contained a version number in it's header.
* Versions of the same library were always backwards compatible. This was Law. Software using an old version of a library must continue to work on future versions. This also meant that developers had to think out thier library API beforehand (because you would have to maintain that API). Libraries could be extended though with extra functions.
* Application programs had to 'open' libraries before using them. When opening a library an application would specify the minimum version that it required of the library. (If no matching or later version was found then the program would have to exit gracefully).
* There tended to be few (compared to Linux anyway) libraries. Libraries tended to be biggish. A few big libraries instead of many tiny libraries. This made them manageable.
* The backwards compatibility rule/law for libraries meant that software could bring it's own version of a library and update the existing version of that library, but *only* if it was a more up-to-date version.
As a previous poster pointed out, a lot of the problem would disappear if people (library writers) maintained compatible interfaces for the same library soname. I'm pretty sure that this is the way it was designed to work.
MO, X is NOT what is slow! It is KDE/Gnome/[insert slow desktop/window manager here]. If you want to see the speed of X all by itself, try typing 'X' at the command line.
Isn't that a bit like saying "My car isn't slow. See how fast it goes with no one in it." Without stuff running on it's not really useful.
(I see your point though. Start up times of apps have less to do with X and more to do with libraries, config files etc).
Sigh. Whoever wrote this apparently has never read or thought about why the *nix filesystem is arranged as it is, or at least what the strengths are of the current setup.
The nix FS was laid out to cater purely to the machine. The user, thier work, thier files and their comfort was an afterthought, (or not considered at all). The primary reason for cleaning up the root directory is because people no longer stay in thier home directories. They need to access drives, media, devices, network shares etc. Stuff which generally lives elsewhere in the filesystem. People should not have to trip over obscure bits of OS while doing real work. Give the OS it's own place (/System) to organise its self, and just get that junk out of the user's face.
Example: "/var => mostly placed under/System" The/var directory exists to collect the stuff that programs have to have write access to, like logs, spools, locks. There is some advantage to mounting e.g./usr/bin read-only on production systems while mounting/var read-write.
What's the objection here?/var could easily be mounted under/System/var too? what's your point?
Example: "/opt =>/Apps" What is the difference between a "Command", an "Executable", and an "App"? Is mozilla an executable or an application?
I didn't write the original paper/post, but I see the distinction. I would put command line based programs under/System/Commands. Most users will never directly use commands. The big ass GUI applications that most users use would be under/Apps. Commands that only root can use could go under/System/Commands/Administration.
This commands/apps is very Amiga-ish actually.
"Applications would no longer need to hard code directory names." Any hardcoded directory compiled into an app is probably a bug (unless it is easily over-ridden with an environment variable). "Set of environmental variables pointing the location of major system directories." What is the difference between hardcoding a directory name like/tmp and hardcoding an environment variable like $TEMP? NOTHING.
/tmp will by necessity be located at/tmp and is hardcoded at build time, while a environment variable like $TEMP could point any where the user wanted and is determined at runtime. (read: internationised dir names).
This is Amiga-ish too. strange. I would love to see this all implemented.
Slashdot Mirror
OK, perhaps you are right, perhaps the current IT market there is healthy. Maybe some people will enjoy a nice job for a while. But the point I'm so trying badly to make ;-) is that the odds of it staying like that are stacked against. Things can only get worse. A cheaper country will come along and the Indians will have to force down wages as much as they can, or the companies will just get up and leave "en masse", probably both.
With the constant threat of "going to China", any good times are not going to stay that way for very long.
--
Simon
And what choice do they have? It's either take the job or be unemployed and have no money food etc, and hope that your familiy can support you. (Welfare? doesn't exist of course)
IBM will have to pay top-dollar in Indian wages in order to attract the best talent.
What makes you think that IBM are even looking for the best talent? Most IT jobs are just boring and don't require geniuses. There will be thousands of people competing against each other for those jobs. That is why IBM wants to go to India. Cheap job market where they can call the shots.
(hence the mad scramble by most Indians to get any possible qualification in IT so they can get on the gravy train.)
And that is exactly why _even_ if it is a gravy train now, it won't stay that way for very long.
How much bargaining power in the job market do you think these Indian workers have?
--
Simon
If the textile industry is any guide, the people will be paid a starvation wage, until the company finds a cheaper source of labour and moves there, leaving the poor workers once again poor and unemployed.
people in India are getting that health care they've always wanted.
You have got to be kidding. ;-D What makes you think there is going to be any extra money for things like health care after IBM or whoever move in and pay as little as possible?
All of this is ignoring things like Free Trade Zones where governments drop taxes (and often human rights) for companies as an incentive for foreign investment...
--
Simon
Which is small price to pay for readable code (and that's assuming that -f and -d, etc is easier to remember than os.path.isfile() and os.path.isdir().) I can't believe that people still think that reducing keystrokes somehow equates to improved programmer effectiveness. It's readability that counts since code is read so much more often than it is written. Hell, even a non-python programmer can read "os.path.isfile()" and guess what it does. I can't say the same about Perl's -f, -d and -e.
--
Simon
But when you do get to the UI, make sure you have your target audience in mind, take the time to design it for maximum usuability,
You've got interface design all confused and mixed up with interface implementation. They are most definately not the same thing. Interface design should definately happen before code is even written. (Sketched out on paper etc) Interface implementation can happen whenever it makes sense for the programmer. (top-down, bottom-up, sideways, whatever.)
You need to realise that the GUI exists to do what the users wishes, and the core code exists to do what the GUI wishes. It's not a case of the GUI being there to expose the functionality of the 'engine' underneath, and the user having to make do with whatever they are given. The GUI must be designed first. How can you write the engine code without knowing what the GUI/user will need to do?
If you design the GUI after the core code is written you will end up with a design suited to the core 'engine' and not to the user.
It's how the user interfaces with your program, so it's going to be the biggest element in how they judge the usuability and usefulness of your project.
It is not just how the user judges your program, for the user it is the program.
--
Simon
The user interface is the first thing that should be designed when developing a program. Even before any code is written, it should be planned out somehow (pencil and paper is good at this stage). Only once you know what you are trying to make should you start working out how it should work internally to achieve that goal.
The interface is the most important thing. It is what you are building. Everything else flows from that.
--
Simon
Interesting that you should pick Moz as an example. Because that is basically how it works inside Moz also. Moz is just a big bunch of C++ modules acting as libraries and an application 'runtime', with the higher level application stuff all being written on top using Javascript, XUL etc.
--
Simon
A Dose of Reality
and also one about the massive increase in depression and other pyschological problems:
Toxic Culture USA
The second link is definately worth reading, and is quite disturbing. IMHO, there is something very very wrong, and it's not just a case of "a few people needing a few drugs".
--
Simon
From the article:
--
Simon
Can you clarify your long term goals with respect to ReiserFS and file system design in geek lay man's terms?
I'm refering to your Future Vision paper in particular. How would this kind of system be used on a day to day basis?
Right now any mention here of adding database like functionality to a file system is met with crude comments about SQL... Some explaination would really help.
cheers,
--
Simon
You can do the free trial that they offer (50 free MP3s). Also, I don't know how much CDs cost where you are, but compared to buying CDs, I've paid $45 for three months and have already downloaded 25 albumns (just joined 2 weeks ago). Not to mention that the music I'm after (electonic, industrial) isn't really available in the shops. If emusic have what you want, it's a great deal.
--
Simon
--
Simon
--
Simon
It ain't the same thing...
--
Simon
examples:
* "SSH shows a warning that the host key has changed. The user ignores it and continues on."
* "The browser warns the a SSL certificate doesn't match the host IP. The user ignores it and continues on."
* "The browser asks if you trust the signer before running some piece of ActiveX. The user ignores it and continues on."
* "The sysadmin warns not to share passwords. The users ignore that too."
Now the question. It seems to me that despite all the work being done in the security field, back in reality things have gone from bad to worse. People constantly sidestep the very systems that are put in place to protect them. Is anything being done in the computer security field to address this important "Human Factors" aspect?
--
Simon
Do these problems really exist? are they bad? Can we have some real evidence instead of just opinion.
--
Simon
These problems made simple OO programming a real trial. Maybe you could say "Well Simon, that's just your C/C++/Java bias there", but I just can't imagine the benefit or desire for having "pass by value" by default for objects... I was hoping that PHP would be a good general script language (the library support is excellent), but that was the deal breaker for me.
--
Simon
This book might be worth checking out too:
http://www.andamooka.org/reader.pl?section=divein
Personally I program with "Python in a Nutshell" by my hand.
--
Simon
Initialise your fields in the __init__() initialiser. Assign the value 'None' to the "not yet used" fields, just like Java. No more "missing until assigned fields".
--
Simon
After spending years using Perl for my small ad hoc stuff, I realised that it just plains sucks. Too many basic things were needlessly difficult. I'm referring to things like defining functions, defining classes, defining and using data structures, plus the unreadable line-noise syntax and the 'under the covers' hidden variable stuff.
Anyway, after that started looking and even went through a PHP phase. Hoping to be also able to use it as a general scripting language. That little "fling" ended after I tried writting Object Oriented code in PHP... the pain!....PHP just does not scale.
So finally I got around to trying out Python. I had heard a few very high recommendations about it in the past. Wow! Everything is as simple as possible, meaning you can keep it in your head for quick access, while still being very powerful. After a few days at Python I tried some metaclass hacking, something I would never dream of in Perl, and it just worked, with almost no effort. Couldn't believe it. Everything is just so fast and simple, and it scales too. I can't praise it enough. I think that most application can and should be written in Python these days. It just makes sense. (Python + Qt is just sweeeet.)
Ok, I'm rambling now. stop
--
Simon
I certainly don't remember hearing anyone complain about it. Seeing the alternative (Windows 3.1 at the time) people quickly realised how much better off we were by doing things this way.
What "new class of problems" are you worried about?
--
Simon
That's not to say that things are not changing. The KDE project for example, aims for maintaining binary compatability during the same major series. Also Mandrake at least, now seem to understand that different major numbers should indicate different libraries. Which is why most of library packages now have the major number in thier names (eg libpcap0, libpng3). Idea being that you can install different versions side by side if needed.
But there are still problems. For example, RPM, when building a package likes to list the library dependancies for the software in the package, but also the libraries that that libraries depend on. (Which is why sometimes you see packages with a dependancy on libopenGL.x or so. That lib is not on most people's machines. It's a case of RPM picking up a dependancy on part of the nVidia drivers installed on the build machine.) You code to the interface, not the implementation!
(IIRC, windows has DLL versioning too. It's optional (!) and of course no-one bothered to use it... sometimes laws have to made.)
--
Simon
Important features of the way AmigaOS libraries worked:
* All libraries were versioned, but not on the file system level. Each library contained a version number in it's header.
* Versions of the same library were always backwards compatible. This was Law. Software using an old version of a library must continue to work on future versions. This also meant that developers had to think out thier library API beforehand (because you would have to maintain that API). Libraries could be extended though with extra functions.
* Application programs had to 'open' libraries before using them. When opening a library an application would specify the minimum version that it required of the library. (If no matching or later version was found then the program would have to exit gracefully).
* There tended to be few (compared to Linux anyway) libraries. Libraries tended to be biggish. A few big libraries instead of many tiny libraries. This made them manageable.
* The backwards compatibility rule/law for libraries meant that software could bring it's own version of a library and update the existing version of that library, but *only* if it was a more up-to-date version.
As a previous poster pointed out, a lot of the problem would disappear if people (library writers) maintained compatible interfaces for the same library soname. I'm pretty sure that this is the way it was designed to work.
anyway, a FYI.
--
Simon
Isn't that a bit like saying "My car isn't slow. See how fast it goes with no one in it." Without stuff running on it's not really useful.
(I see your point though. Start up times of apps have less to do with X and more to do with libraries, config files etc).
--
Simon
The nix FS was laid out to cater purely to the machine. The user, thier work, thier files and their comfort was an afterthought, (or not considered at all). The primary reason for cleaning up the root directory is because people no longer stay in thier home directories. They need to access drives, media, devices, network shares etc. Stuff which generally lives elsewhere in the filesystem. People should not have to trip over obscure bits of OS while doing real work. Give the OS it's own place (/System) to organise its self, and just get that junk out of the user's face.
What's the objection here? /var could easily be mounted under /System/var too? what's your point?
I didn't write the original paper/post, but I see the distinction. I would put command line based programs under /System/Commands. Most users will never directly use commands. The big ass GUI applications that most users use would be under /Apps. Commands that only root can use could go under /System/Commands/Administration.
This commands/apps is very Amiga-ish actually.
This is Amiga-ish too. strange. I would love to see this all implemented.
--
Simon