Right. I completely agree. Based on the word "employer", I assumed she wouldn't be a freelancer. But if she is, it is reasonable to expect her to bring her own tools - and be compensated for it by getting paid more.
If the employer requires specific software, I think it is reasonable that they also provide it. I think it is reasonable that they also provide it. Goes with the whole package of desk, chair, computer, and all that. Of course, that doesn't necessarily extend to outside the office, but you could negotiate about that.
I liked that review. It was interesting enough for me to read it in full, and you seems to have covered everything I wanted to know, with no uncalled for overhyping or bashing.
One minor gripe I have, not necessarily with your review per se but in general:
Sure, GNOME and OpenOffice.org take a long time to start up, and Flash runs like molasses unless you have a beast of a CPU, but let's not hold that against the devices. It's the software that makes it that way. Every time a low-power device is introduced, people note that it doesn't run $heavy_software_of_choice speedily. Well, of course not. That software was developed so that it runs passably on the fastest generation of desktop hardware.
Imagine not, what the experience could be like running heavy software on faster hardware. Imagine what the experience could be like running lighter software on the same hardware.
``And the very first thing they did, within mere days of the acquisition, is they took his ultra-efficient, elegant little tools and put a 200KB EULA popup into every one of them.''
A fine example of how proprietary software is so much more user-friendly than open-source software.
``A GUI popup.
Even into the command line tools.''
That, of course, is to make them more user-friendly. Everybody knows the command-line is just for Unix hippies who still live in the 1970s.
I think the important thing to remember here is that estimates are _estimates_.
Based on limited information about what the customer wants, the availability/productivity of the team (people get sick, have good days and bad days,...), the bugs in the libraries you're working with, and the occurrence of disasters, you come up with an honest estimate.
It may be wildly wrong.
But that's your estimate.
Now, if the organization is going to raise that estimate to a sort of divine decree that The Project Shall Take That Long, and you'll only get resources for that many hours, and there will be a deadline which has already been agreed on with the customer, and you will get flamed if you miss the deadline (all these things are very likely), then perhaps you'd best not tell anyone your honest estimate.
Don't tell anyone how long you think it will take. Tell them how long you will need to be sure you get everything implemented, even if your team is sick half of the time, the scope keeps changing, and the libraries are so buggy that you'll end up spending more time than if you had written them yourself. Cause that's what will happen. And if, by some miracle, you still manage to finish early, that will be a happy surprise for management and a good mark for you.
I apply this technique, and while my colleagues always think my "estimates" are ridiculously high and what we end up reporting is usually adjusted downward a bit, it's spooky how often the ridiculously high numbers turn out to be right.
This is pure speculation, but I wouldn't be surprised if IBM were supporting Linux on POWER because AIX has become or is becoming too expensive to maintain. They're still working on AIX and still shipping it, and it may still work better than Linux on POWER, but in the end, one IBM can't compete with a system that has both the open source community and a lot of major corporations backing it. So they've done the wise thing and started supporting Linux, so that they can eventually axe AIX and get a lot of work done on their new OS for free.
Yep. What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those.''
Common Lisp. There are several compilers for it that actually make it efficient. I've even seen Lisp programs beat C, C++, and Java.
Current Ruby implementations are dog slow even by dynamic language standards, but let's not forget that it's easy to interface to C from Ruby. You can alternate hard and soft layers and get _both_ rapid development and fast software.
``(3) It's not suitable for large projects.''
I tend to agree with that, but I also think most projects aren't large or at least _shouldn't_ be large. You can usually break things up in parts that are a couple hundred lines (in Ruby) at _most_, and then you don't need any "large project features" in your language. But that doesn't necessarily mean Ruby is a good choice for large projects.
Having used both Rails (1.something) and Spring (2.something), I can tell you which I prefer.
Hint: it's not the one that tosses out the compile-time checking and performance of your so-called real programming language by having you write everything in XML.
Also, I much prefer the bastard child of several useful and expressive programming languages to a language that has set the world back a decade or so by having people re-invent and re-implement things that were working years before it.
Apologies if this comes across as if I think the world would be a better place if Java and Spring had never seen the light of day. I don't think that's really the way it is. On the other hand, I'm not convinced it actually isn't.
2. It's slow
7. The ruby community is full of over-hyping zelous twits
Rails sucks because:
6. It's not lightweight enough
Ruby is awesome because:
4. I used to write PHP, Ruby's been a godsend
5. There are so many motivated and innovative people in the community
6. It's featureful
Full disclosure:
Ruby sure isn't perfect, but, of all the languages I've tried (and there are many), it seems to me Ruby sucks the least. I use it whenever I can, which is when another language isn't a better choice (e.g. speed is required) or mandated (e.g. required to do the project in Java). Current implementations are dog slow, and, as always, there are people who will hype it up to ridiculous levels. But hey, that's how Java got big.;-)
I don't really use Rails much, and I probably wouldn't have built it as it is, but I enjoyed working with it in the past. At the time, it did certainly rock the world. Still, I think Ruby's main strength is in quickly building _simple_ things and its power to make lots of things simple. Grab the modules you need and/or (have someone) tailor the language to your needs, then write your program in a few lines of code. That's where Ruby shines.
I congratulate SourceForge on empowering their users to choose for themselves, but I'm still moving my stuff elsewhere. Not just because of the country restrictions, but also because I don't like the new (slow, heavy, buggy) interface, and because I've been getting dropped connections from them.
The question is: what is the best place to move to?
I've worked in organizations that developed software, from small shops where the programmers talked to the customers directly, and huge organizations with several layers in between.
In the small shops, the programmers know what is wrong with the software they make. They know, because the users tell them. They phone in and say "X doesn't work", and the programmer just keeps asking questions until they can reproduce the problem. If they don't sort it out over the phone, one visits the other and the problem gets demonstrated, documented, and fixed.
In the large organizations, the programmers often don't even know what the software is supposed to do, much less how it fails to do it. I've literally seen developers ship software that was so broken it didn't even run. Often, the developers wouldn't hear about it, because the organization had an entire department dedicated to filtering bug reports. And this made sense, because most of the reports weren't for actual bugs in the software. But, in the end, a lot of users just stopped even filing the reports, convinced that they wouldn't be picked up, anyway.
The funny thing is that the latter organization actually delivered a more pleasant experience for both the developers and the users. Why? Well, let's just say that software developers aren't always known for their good people skills. Users aren't, either. The large organization, however, had (surprise, surprise) an entire department dedicated to sweet-talking the users, and an internal code to prevent stepping on the developers' toes. There were never bugs, there were only ever things that would be improved in the next release. And that's something that everybody can live with.
It is fully possible that what happened here is due to bugs in the VM rather than in the OS.
For the record, Win7 did actually run in the VM at first. It just lacked support for the emulated sound card, which I read would be available after running Windows Update. So I ran Windows Update. This caused the system to trash (constant disk activity) for over 48 hours, after which it crashed. The screenshots are what I get when I boot the system after the crash.
Meanwhile, I have the same version of Windows 7 (build 7100) running on my real hardware. It worked out of the box, except that it wouldn't connect to my network. Since I don't really need network access (I only use it to play a single-player game), I have made no effort to debug that issue. It also makes it impossible to run Windows Update, so I don't fear that I will hose this install like I did the other. And I don't worry about malware and privacy issues, either. So I'm perfectly happy with it this way.
Yes, I did click that button. It didn't give me anything helpful. There is also another screen I once managed to get where I could perform various automagic problem solving actions. None of them fixed the problem. I also don't know what the problem was; the system never really tells you.
All in all, it is a good example of what you get when you try to keep the technical details hidden from your users: the system tells you something is wrong, but not _what_ is wrong. It then offers you to try and fix it, without telling you what that is going to do. And whatever that did didn't alleviate the still unknown problem.
Anyway, this isn't the version actually released as a commercial product, and it isn't running on a production machine, so I'm not getting too excited about it. I still thought "Windows 7 in 7 Screenshots" made a nice slogan, though.:-)
``Saying that it's "nagging" the user to pay up, is nothing more than using some fine choice of words to make it look bad on Microsoft.''
Actually, I think that is the technical term for it. Software that does this is called nagware.
``Next up: Adobe nags the users after one month of using their trial software. Oh, the horror!''
Actually, I do think it's pretty horrible. I guess you get used to it, but having switched to open source software a long time ago, I half jump out of my skin with fear, annoyance, and fury when I find myself on Windows, especially in the "as shipped" or the "my computer is slow" states. It's like every second program on the computer is trying to get your attention for something or other: your computer may be at risk, your virus definitions are out of date, your trial period has expired, a new Java update is available, checking for new versions of your Firefox plugins, please click "Allow" if you want to allow Windows to start the program you just told it to start, and on and on. And don't get me started on the processes of software installation, hardware installation, or updates.
Being used to Debian, the Windows desktop is horribly distracting. I can completely understand why users give up reading the messages that pop up on their screens and just want them to go away as quickly as possible.
Sorry for the rant. I feel better now that's off my chest.
You wrote you need more manpower and testing. How hard is it for, say, someone proficient in C to get into video driver development? Do you have any pointers to materials that would help one get started?
Now there's a good idea. I'd mod you up if I could.
The way I see it, the number one problem with credit cards is that all the verification steps do basically amount to nothing... everything you need is printed on the card, so what is verified is neither that you have the card nor that you know some secret.
What you propose completely changes that.
By adding a number that changes over time, you foil re-use. Someone can copy the other things on your card, but they will be useless without the card.
Add some sort of secret and you have good two-factor authentication.
Isn't it time we started using hosting services located outside the USA? This is not the only restriction that the US impose. I would imagine a hosting service could serve its community better if it were based in a less restrictive jurisdiction. What jurisdictions are good for hosting software and information, and what hosting services operate out of such jurisdictions?
``This suggests an economics / game theory problem: Could you come up with a system that takes into account the incentives of parties on both sides, and that prevents huge legal bills from being generated?''
In as far as I understand the way things work in the USA, I think this is partially already in place. Fees are not automatically awarded, but rather only awarded for cases in which the outcome should have been obvious. That is, if I sue you, but it should have been obvious that I wasn't going to win, I can expect to have to pay for your fees. Conversely, you can jack up the bill as far as is necessary to win the case that I shouldn't have brought in the first place.
For cases that don't fall into this category, we can both expect to have to pay the fees on our respective sides. This gives us both an incentive to give our fees low.
Finally, there is a possible problem where a lawsuit is worth bringing, but one of the sides can't afford to pay the fees. For such cases, there are lawyers who work on a "no cure, no pay" basis, which means you don't pay them anything if they don't win the case for you. Supposedly, if you win the case, you are awarded enough to be able to pay them.
Now, here is one idea to further limit costs: suppose we limit the fees to be awarded to the minimum of what either party incurred. That is, if I bring a case against you, and you insist on hiring 80 lawyers against my one, then you can expect to be awarded at most what I paid for my lawyer. Supposedly, since I paid that much, I considered it a reasonable cost. Whatever you spent extra is your own choice and comes out of your own pocket regardless. Just an idea to ponder.
1) The difference in kinetic energy before and after the collision. If the kinetic energy after the collision is lower, there must be more mass (recall that mass is energy) to compensate. Hence, you may end up with more particles than you started with.
2) Particles do not necessarily survive a collision. Therefore, you may end up with different particles than you started with. These may have resting masses lower than two proton masses if the kinetic energy is higher.
In short, should you create a black hole, it could have a mass of more than two proton masses, or less.
Slashdot Mirror
Horses for courses. If you want reproducible, you don't want true random. If you want security, you do.
``Use a debugger or code analysis tool to find the main execution paths (what calls what and when, etc). Diagram that up on the wall really large.''
Actually, I figure that there must be tools specifically for finding execution paths. What are the tools people use for various languages?
Right. I completely agree. Based on the word "employer", I assumed she wouldn't be a freelancer. But if she is, it is reasonable to expect her to bring her own tools - and be compensated for it by getting paid more.
If the employer requires specific software, I think it is reasonable that they also provide it. I think it is reasonable that they also provide it. Goes with the whole package of desk, chair, computer, and all that. Of course, that doesn't necessarily extend to outside the office, but you could negotiate about that.
Hi,
I liked that review. It was interesting enough for me to read it in full, and you seems to have covered everything I wanted to know, with no uncalled for overhyping or bashing.
One minor gripe I have, not necessarily with your review per se but in general:
Sure, GNOME and OpenOffice.org take a long time to start up, and Flash runs like molasses unless you have a beast of a CPU, but let's not hold that against the devices. It's the software that makes it that way. Every time a low-power device is introduced, people note that it doesn't run $heavy_software_of_choice speedily. Well, of course not. That software was developed so that it runs passably on the fastest generation of desktop hardware.
Imagine not, what the experience could be like running heavy software on faster hardware. Imagine what the experience could be like running lighter software on the same hardware.
``And the very first thing they did, within mere days of the acquisition, is they took his ultra-efficient, elegant little tools and put a 200KB EULA popup into every one of them.''
A fine example of how proprietary software is so much more user-friendly than open-source software.
``A GUI popup.
Even into the command line tools.''
That, of course, is to make them more user-friendly. Everybody knows the command-line is just for Unix hippies who still live in the 1970s.
I think the important thing to remember here is that estimates are _estimates_.
Based on limited information about what the customer wants, the availability/productivity of the team (people get sick, have good days and bad days, ...), the bugs in the libraries you're working with, and the occurrence of disasters, you come up with an honest estimate.
It may be wildly wrong.
But that's your estimate.
Now, if the organization is going to raise that estimate to a sort of divine decree that The Project Shall Take That Long, and you'll only get resources for that many hours, and there will be a deadline which has already been agreed on with the customer, and you will get flamed if you miss the deadline (all these things are very likely), then perhaps you'd best not tell anyone your honest estimate.
Don't tell anyone how long you think it will take. Tell them how long you will need to be sure you get everything implemented, even if your team is sick half of the time, the scope keeps changing, and the libraries are so buggy that you'll end up spending more time than if you had written them yourself. Cause that's what will happen. And if, by some miracle, you still manage to finish early, that will be a happy surprise for management and a good mark for you.
I apply this technique, and while my colleagues always think my "estimates" are ridiculously high and what we end up reporting is usually adjusted downward a bit, it's spooky how often the ridiculously high numbers turn out to be right.
Why do you suppose being able to buy similar systems from multiple vendors wouldn't drive down the price?
This is pure speculation, but I wouldn't be surprised if IBM were supporting Linux on POWER because AIX has become or is becoming too expensive to maintain. They're still working on AIX and still shipping it, and it may still work better than Linux on POWER, but in the end, one IBM can't compete with a system that has both the open source community and a lot of major corporations backing it. So they've done the wise thing and started supporting Linux, so that they can eventually axe AIX and get a lot of work done on their new OS for free.
``(2) It's slow.
Yep. What do you expect? It's an interpreted, dynamic language. Nobody has yet succeeded in making a true compiler for those.''
Common Lisp. There are several compilers for it that actually make it efficient. I've even seen Lisp programs beat C, C++, and Java.
Current Ruby implementations are dog slow even by dynamic language standards, but let's not forget that it's easy to interface to C from Ruby. You can alternate hard and soft layers and get _both_ rapid development and fast software.
``(3) It's not suitable for large projects.''
I tend to agree with that, but I also think most projects aren't large or at least _shouldn't_ be large. You can usually break things up in parts that are a couple hundred lines (in Ruby) at _most_, and then you don't need any "large project features" in your language. But that doesn't necessarily mean Ruby is a good choice for large projects.
Having used both Rails (1.something) and Spring (2.something), I can tell you which I prefer.
Hint: it's not the one that tosses out the compile-time checking and performance of your so-called real programming language by having you write everything in XML.
Also, I much prefer the bastard child of several useful and expressive programming languages to a language that has set the world back a decade or so by having people re-invent and re-implement things that were working years before it.
Apologies if this comes across as if I think the world would be a better place if Java and Spring had never seen the light of day. I don't think that's really the way it is. On the other hand, I'm not convinced it actually isn't.
My pick:
Ruby sucks because:
2. It's slow
7. The ruby community is full of over-hyping zelous twits
Rails sucks because:
6. It's not lightweight enough
Ruby is awesome because:
4. I used to write PHP, Ruby's been a godsend
5. There are so many motivated and innovative people in the community
6. It's featureful
Full disclosure:
Ruby sure isn't perfect, but, of all the languages I've tried (and there are many), it seems to me Ruby sucks the least. I use it whenever I can, which is when another language isn't a better choice (e.g. speed is required) or mandated (e.g. required to do the project in Java). Current implementations are dog slow, and, as always, there are people who will hype it up to ridiculous levels. But hey, that's how Java got big. ;-)
I don't really use Rails much, and I probably wouldn't have built it as it is, but I enjoyed working with it in the past. At the time, it did certainly rock the world. Still, I think Ruby's main strength is in quickly building _simple_ things and its power to make lots of things simple. Grab the modules you need and/or (have someone) tailor the language to your needs, then write your program in a few lines of code. That's where Ruby shines.
I congratulate SourceForge on empowering their users to choose for themselves, but I'm still moving my stuff elsewhere. Not just because of the country restrictions, but also because I don't like the new (slow, heavy, buggy) interface, and because I've been getting dropped connections from them.
The question is: what is the best place to move to?
You are so right.
I've worked in organizations that developed software, from small shops where the programmers talked to the customers directly, and huge organizations with several layers in between.
In the small shops, the programmers know what is wrong with the software they make. They know, because the users tell them. They phone in and say "X doesn't work", and the programmer just keeps asking questions until they can reproduce the problem. If they don't sort it out over the phone, one visits the other and the problem gets demonstrated, documented, and fixed.
In the large organizations, the programmers often don't even know what the software is supposed to do, much less how it fails to do it. I've literally seen developers ship software that was so broken it didn't even run. Often, the developers wouldn't hear about it, because the organization had an entire department dedicated to filtering bug reports. And this made sense, because most of the reports weren't for actual bugs in the software. But, in the end, a lot of users just stopped even filing the reports, convinced that they wouldn't be picked up, anyway.
The funny thing is that the latter organization actually delivered a more pleasant experience for both the developers and the users. Why? Well, let's just say that software developers aren't always known for their good people skills. Users aren't, either. The large organization, however, had (surprise, surprise) an entire department dedicated to sweet-talking the users, and an internal code to prevent stepping on the developers' toes. There were never bugs, there were only ever things that would be improved in the next release. And that's something that everybody can live with.
Hello Anonymous Coward,
It is fully possible that what happened here is due to bugs in the VM rather than in the OS.
For the record, Win7 did actually run in the VM at first. It just lacked support for the emulated sound card, which I read would be available after running Windows Update. So I ran Windows Update. This caused the system to trash (constant disk activity) for over 48 hours, after which it crashed. The screenshots are what I get when I boot the system after the crash.
Meanwhile, I have the same version of Windows 7 (build 7100) running on my real hardware. It worked out of the box, except that it wouldn't connect to my network. Since I don't really need network access (I only use it to play a single-player game), I have made no effort to debug that issue. It also makes it impossible to run Windows Update, so I don't fear that I will hose this install like I did the other. And I don't worry about malware and privacy issues, either. So I'm perfectly happy with it this way.
Yes, I did click that button. It didn't give me anything helpful. There is also another screen I once managed to get where I could perform various automagic problem solving actions. None of them fixed the problem. I also don't know what the problem was; the system never really tells you.
All in all, it is a good example of what you get when you try to keep the technical details hidden from your users: the system tells you something is wrong, but not _what_ is wrong. It then offers you to try and fix it, without telling you what that is going to do. And whatever that did didn't alleviate the still unknown problem.
Anyway, this isn't the version actually released as a commercial product, and it isn't running on a production machine, so I'm not getting too excited about it. I still thought "Windows 7 in 7 Screenshots" made a nice slogan, though. :-)
``Saying that it's "nagging" the user to pay up, is nothing more than using some fine choice of words to make it look bad on Microsoft.''
Actually, I think that is the technical term for it. Software that does this is called nagware.
``Next up: Adobe nags the users after one month of using their trial software. Oh, the horror!''
Actually, I do think it's pretty horrible. I guess you get used to it, but having switched to open source software a long time ago, I half jump out of my skin with fear, annoyance, and fury when I find myself on Windows, especially in the "as shipped" or the "my computer is slow" states. It's like every second program on the computer is trying to get your attention for something or other: your computer may be at risk, your virus definitions are out of date, your trial period has expired, a new Java update is available, checking for new versions of your Firefox plugins, please click "Allow" if you want to allow Windows to start the program you just told it to start, and on and on. And don't get me started on the processes of software installation, hardware installation, or updates.
Being used to Debian, the Windows desktop is horribly distracting. I can completely understand why users give up reading the messages that pop up on their screens and just want them to go away as quickly as possible.
Sorry for the rant. I feel better now that's off my chest.
``and random restarts of Windows 7 was my idea!''
Does this satisfy your need? Windows 7 in 7 Screenshots.
You wrote you need more manpower and testing. How hard is it for, say, someone proficient in C to get into video driver development? Do you have any pointers to materials that would help one get started?
Now there's a good idea. I'd mod you up if I could.
The way I see it, the number one problem with credit cards is that all the verification steps do basically amount to nothing ... everything you need is printed on the card, so what is verified is neither that you have the card nor that you know some secret.
What you propose completely changes that.
By adding a number that changes over time, you foil re-use. Someone can copy the other things on your card, but they will be useless without the card.
Add some sort of secret and you have good two-factor authentication.
Family life?
Social involvement?
Outside work???
Isn't it time we started using hosting services located outside the USA? This is not the only restriction that the US impose. I would imagine a hosting service could serve its community better if it were based in a less restrictive jurisdiction. What jurisdictions are good for hosting software and information, and what hosting services operate out of such jurisdictions?
And, as always, these numbers may or may not be meaningful ... measure in different places and you'll get different results.
``This suggests an economics / game theory problem: Could you come up with a system that takes into account the incentives of parties on both sides, and that prevents huge legal bills from being generated?''
In as far as I understand the way things work in the USA, I think this is partially already in place. Fees are not automatically awarded, but rather only awarded for cases in which the outcome should have been obvious. That is, if I sue you, but it should have been obvious that I wasn't going to win, I can expect to have to pay for your fees. Conversely, you can jack up the bill as far as is necessary to win the case that I shouldn't have brought in the first place.
For cases that don't fall into this category, we can both expect to have to pay the fees on our respective sides. This gives us both an incentive to give our fees low.
Finally, there is a possible problem where a lawsuit is worth bringing, but one of the sides can't afford to pay the fees. For such cases, there are lawyers who work on a "no cure, no pay" basis, which means you don't pay them anything if they don't win the case for you. Supposedly, if you win the case, you are awarded enough to be able to pay them.
Now, here is one idea to further limit costs: suppose we limit the fees to be awarded to the minimum of what either party incurred. That is, if I bring a case against you, and you insist on hiring 80 lawyers against my one, then you can expect to be awarded at most what I paid for my lawyer. Supposedly, since I paid that much, I considered it a reasonable cost. Whatever you spent extra is your own choice and comes out of your own pocket regardless. Just an idea to ponder.
You are forgetting two things, though:
1) The difference in kinetic energy before and after the collision. If the kinetic energy after the collision is lower, there must be more mass (recall that mass is energy) to compensate. Hence, you may end up with more particles than you started with.
2) Particles do not necessarily survive a collision. Therefore, you may end up with different particles than you started with. These may have resting masses lower than two proton masses if the kinetic energy is higher.
In short, should you create a black hole, it could have a mass of more than two proton masses, or less.