The entry level MacBook is $1,099. To get a 13.3" laptop with 2.0GHZ C2D, 1GB RAM and 80GB HDD from System 76, I have to shell out $1,414, and that can't run Mac OS X (choice is a good thing, right?).
Employee satisfaction is absolutely essential
on
Pay vs. Happiness
·
· Score: 1
When I was a kid, I worked in a bakery. I worked alone most of the time and had widely varied duties.
For several months my opinions on various weighty matters were taken into account and even acted on, despite me being a teenager. Business got better, and I gained respect.
The a decree came down from on high that the overarching company management wanted to "increase productivity" and polish the store's "image". So the entire place was completely torn apart and rebuilt in a way that made no sense just so it'd look better in pictures the consultant submitted to the corporate PHBs.
Business suffered, my opinion was no longer worth squat, and everyone stopped caring. No one bothered to work hard at anything and the place became a mess.
That bakery went out of business because they didn't recognize the importance of employees who cared about what they're doing.
The problem is, of course, that these "Linux users" will show up with heavily customised installs that are the end result of days (if not weeks) of setup and configuration requiring non-trivial knowledge.
Or, you know... they'll have stock 30 minute installs of something like Ubuntu, Fedora or SuSE.
Question 4: Why announce this chip swap a year before it will even begin for customers?
For developers... ?
No. Cringely had this one right. They could have gotten by with dev kits seeded under NDA to big developers, and the smoothness of the Xcode "universal binary" compilation would take care of everyone else pretty well.
I suspect Apple's biggest concern was Wall Street. PowerPCs are still doing pretty well. If they aren't in a year's time, though, the analysts can see a solution and they won't be as tempted to panic.
The real danger isn't security. It's employees getting hit with tons of extraneous messages because their instant messaging client is exposed to the rest of the world.
If I'm working in a call center, some guy at home shouldn't be able to directly message me. That should be strictly for in-company discussions.
Problem is, a lot of Microsoft's value is tied up in their stock. If they tried to actually do this, their capital would rapidly vanish due to investors jumping off a sinking ship.
Microsoft holds off on itself suppot either format, letting others (like Apple) make a solid investment in Blu-Ray, then comes out with strong, integrated support for HD-DVD but finds a way to cripple use of Blu-Ray devices with Windows. A bug forced onto machines by way of a "Critical Security Update" would work nicely.
I don't think Cairo necessarily means things will suddenly start to look better, but they don't necessarily have to. GTK+ apps already look pretty good with a decent theme.
It's sufficient if apps continue to look the way they do, and see a performance boost. In fact, I think I'd rather see than than fancier graphics and no speed improvements.
Absolutely. So far I've seen Firefox and Thunderbird as the two most powerful vectors to Linux. Most people spend their time sending e-mail and browsing the web. You show them Firefox and Thunderbird and get them to love those programs and all of a sudden you can start selling Linux by saying "includes your favorite Mozilla software!"
I strongly suspect the Microsoft solution will still be to store metadata about files in one or a few monolithic "dictionaries", rather than more directly attached to the file.
The downside to this approach would be making it difficult to send the metadata with the file, unless sending it to another computer with the same search capabilities. I can see someone coming from the latest XP service pack sending a file laden with omments and such to a Windows 2000 user, the file getting edited, then when it gets sent back, being utterly devoid of any metadata.
I think he's saying that for someone who's going to be using Linux on a regular basis, there are going to be times when it's helpful to have some more "advanced" skills, and thus it's a bad idea to use a distro that glosses over things and doesn't force you to deal with the details and learn important skills.
Either namespaces or comprehensively object-oriented data types and libraries would do the trick. Namespaces would be less spectacular, but still useful.
All of these demonstrate a basic redundancy that's rather annoying.
No repeating the type of the variable when any decent compiler or runtime should be able to figure that out, and no wondering where the "subject" occurs in the parameter list.
Yes, I know, PHP5 has a much better OO model. It still means squat until the standard library actually promotes its use and makes everyday tasks easier and more intuitive.
Backwards compatibility is a bogus reason for not doing it, too. Those truly concerned with backwards compatibility will use PHP4 anyway, and many will be for quite some time. PHP5 should have been a major departure. The emergence of ASP.NET, and the fact that it meant the closest competitor to PHP was making a huge break from the past, opened up a window for PHP to do the same. I fear that window has been missed.
Yes, you've aptly proved that it's possible to do many of the same things in C that you can in C++.
However, the C++ way generally is more convenient, and I would go so far as to say that convenience, in the right measure, makes for better code. Rather than inventing your own wrappers for freeing memory, for instance, with "delete" all of that gets put into a destructor which can be easily found in any class that implements one.
Obviously you can go overboard on syntax, but clearly if something becomes fundamental to the language, then there's a strong argument for adding syntax to support it, if only to prevent people from reinventing the wheel.
Does this work because object provides a default implementation of __len__(), which raises a TypeError?
I'm not sure I'm fond of this regardless of how it's implemented. The AttributeError or NoMethodError (in Ruby) clearly indicates a missing method. The "len() of unsized object" I'm sure has meaning to an experienced Python programmer, but it seems like handling errors is the wrong place for abstraction.:-)
YAML differs somewhat from Python in this regard. When a Ruby programmer deals with YAML, it's largely by reading in the YAML code, which creates a Ruby object, dealing with that object, then calling another method to reserialize that object to YAML.
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class Foo: ... pass ... >>> len(Foo()) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: Foo instance has no attribute '__len__' >>>
It doesn't appear that len() intercepts AttributeError exceptions and reraises them as TypeError exceptions.
array.__len__(). The double underscore convetion is really widely used in python, and the global level functions that wrap them are a common Python idiom. They're the Python version of Java Interfaces (you can iterate over anything that implements __iter__, you can convert to a string anything that implements __str__, etc. You can get the length of anything that implements __len__). I don't see this as tacked on OO, I see this as a very powerful way of integrating objects. As an excellent example, you can call anything that implements __call__, using the standard () syntax (I understand Ruby has a similiar concept).
I think the Ruby take on this, and my own feeling, is that this represents an unnecessary level of abstraction.
Why use len(array), which calls array.__len__(), when you can just call array.length() and skip the extra step? In a language that doesn't statically type variables, this doesn't make things any less flexible. "array" could be of any type, and as long as it has a "length" method, everything's fine.
Anybody who knows even the first thing about web-based applications knows you still have to do every bit as much validation on the server-side, regardless of what validation you do on the client-side, because the client can never be trusted to send back valid input.
Client-side validation is a convenience for the client. Nothing more.
If Mozilla doesn't patent it, Microsoft will, and then they'll use it to shut everyone else down.
I don't see anything wrong with decent organizations patenting good concepts just to prevent companies like Microsoft from having the same opportunity.
Slashdot Mirror
I did thius earlier today. Went to Crucial. It's $500 each for the necessary modules. That's not too terribly out of line with Apple's $1200.
nd even if you just run Ubuntu on the MacBook... it's still $300 cheaper.
The entry level MacBook is $1,099. To get a 13.3" laptop with 2.0GHZ C2D, 1GB RAM and 80GB HDD from System 76, I have to shell out $1,414, and that can't run Mac OS X (choice is a good thing, right?).
When I was a kid, I worked in a bakery. I worked alone most of the time and had widely varied duties.
For several months my opinions on various weighty matters were taken into account and even acted on, despite me being a teenager. Business got better, and I gained respect.
The a decree came down from on high that the overarching company management wanted to "increase productivity" and polish the store's "image". So the entire place was completely torn apart and rebuilt in a way that made no sense just so it'd look better in pictures the consultant submitted to the corporate PHBs.
Business suffered, my opinion was no longer worth squat, and everyone stopped caring. No one bothered to work hard at anything and the place became a mess.
That bakery went out of business because they didn't recognize the importance of employees who cared about what they're doing.
Or, you know... they'll have stock 30 minute installs of something like Ubuntu, Fedora or SuSE.
Question 4: Why announce this chip swap a year before it will even begin for customers? For developers... ? No. Cringely had this one right. They could have gotten by with dev kits seeded under NDA to big developers, and the smoothness of the Xcode "universal binary" compilation would take care of everyone else pretty well. I suspect Apple's biggest concern was Wall Street. PowerPCs are still doing pretty well. If they aren't in a year's time, though, the analysts can see a solution and they won't be as tempted to panic.
The real danger isn't security. It's employees getting hit with tons of extraneous messages because their instant messaging client is exposed to the rest of the world.
If I'm working in a call center, some guy at home shouldn't be able to directly message me. That should be strictly for in-company discussions.
Problem is, a lot of Microsoft's value is tied up in their stock. If they tried to actually do this, their capital would rapidly vanish due to investors jumping off a sinking ship.
Microsoft holds off on itself suppot either format, letting others (like Apple) make a solid investment in Blu-Ray, then comes out with strong, integrated support for HD-DVD but finds a way to cripple use of Blu-Ray devices with Windows. A bug forced onto machines by way of a "Critical Security Update" would work nicely.
I don't think Cairo necessarily means things will suddenly start to look better, but they don't necessarily have to. GTK+ apps already look pretty good with a decent theme. It's sufficient if apps continue to look the way they do, and see a performance boost. In fact, I think I'd rather see than than fancier graphics and no speed improvements.
Hey. Microsoft could have figured out that it was crap. They kept it alive and made it *the* official anti-spyware for Windows...
They're just as responsible for anything that goes wrong as GIANT.
Absolutely. So far I've seen Firefox and Thunderbird as the two most powerful vectors to Linux. Most people spend their time sending e-mail and browsing the web. You show them Firefox and Thunderbird and get them to love those programs and all of a sudden you can start selling Linux by saying "includes your favorite Mozilla software!"
GAIM is a good idea even when the system is working correctly. ;-)
I strongly suspect the Microsoft solution will still be to store metadata about files in one or a few monolithic "dictionaries", rather than more directly attached to the file. The downside to this approach would be making it difficult to send the metadata with the file, unless sending it to another computer with the same search capabilities. I can see someone coming from the latest XP service pack sending a file laden with omments and such to a Windows 2000 user, the file getting edited, then when it gets sent back, being utterly devoid of any metadata.
I think he's saying that for someone who's going to be using Linux on a regular basis, there are going to be times when it's helpful to have some more "advanced" skills, and thus it's a bad idea to use a distro that glosses over things and doesn't force you to deal with the details and learn important skills.
Either namespaces or comprehensively object-oriented data types and libraries would do the trick. Namespaces would be less spectacular, but still useful.
:: takes the place of wondering how the words in a name are separated.
All of these demonstrate a basic redundancy that's rather annoying.
$foo = "Hello world";
str_replace("world", "World!", $foo);
I know $foo is a string. I created it.
$foo = "Hello world";
string::replace("world", "World!", $foo);
Would be slightly better, since the
Even better would be:
$foo = "Hello world";
$foo->replace("world", "World!");
No repeating the type of the variable when any decent compiler or runtime should be able to figure that out, and no wondering where the "subject" occurs in the parameter list.
Yes, I know, PHP5 has a much better OO model. It still means squat until the standard library actually promotes its use and makes everyday tasks easier and more intuitive.
Backwards compatibility is a bogus reason for not doing it, too. Those truly concerned with backwards compatibility will use PHP4 anyway, and many will be for quite some time. PHP5 should have been a major departure. The emergence of ASP.NET, and the fact that it meant the closest competitor to PHP was making a huge break from the past, opened up a window for PHP to do the same. I fear that window has been missed.
I think they're even more powerful when used to replace function pointers.
#include <string>
#include <sstream>
#include <iostream>
char upper_case(char input) {
if (input >= 'a' && input <= 'z')
return input - 32;
else
return input;
}
template <typename T>
std::string transform_string(std::string str, T func) {
std::stringstream ss;
for (std::string::iterator i(str.begin()); i != str.end(); i++)
ss << func(*i);
return ss.str();
}
int main() {
std::cout << transform_string("hello", upper_case) << std::endl;
return 0;
}
Yes, you've aptly proved that it's possible to do many of the same things in C that you can in C++.
However, the C++ way generally is more convenient, and I would go so far as to say that convenience, in the right measure, makes for better code. Rather than inventing your own wrappers for freeing memory, for instance, with "delete" all of that gets put into a destructor which can be easily found in any class that implements one.
Obviously you can go overboard on syntax, but clearly if something becomes fundamental to the language, then there's a strong argument for adding syntax to support it, if only to prevent people from reinventing the wheel.
You miss what is probably the biggest advantage of C++ (and possibly one of the most controversial).
Templates allow for some incredibly slick code, and vastly improve both programmer productivity and type safety.
Does this work because object provides a default implementation of __len__(), which raises a TypeError?
:-)
I'm not sure I'm fond of this regardless of how it's implemented. The AttributeError or NoMethodError (in Ruby) clearly indicates a missing method. The "len() of unsized object" I'm sure has meaning to an experienced Python programmer, but it seems like handling errors is the wrong place for abstraction.
YAML differs somewhat from Python in this regard. When a Ruby programmer deals with YAML, it's largely by reading in the YAML code, which creates a Ruby object, dealing with that object, then calling another method to reserialize that object to YAML.
Python code requires more direct editing.
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... pass
...
>>> len(Foo())
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: Foo instance has no attribute '__len__'
>>>
It doesn't appear that len() intercepts AttributeError exceptions and reraises them as TypeError exceptions.
array.__len__(). The double underscore convetion is really widely used in python, and the global level functions that wrap them are a common Python idiom. They're the Python version of Java Interfaces (you can iterate over anything that implements __iter__, you can convert to a string anything that implements __str__, etc. You can get the length of anything that implements __len__). I don't see this as tacked on OO, I see this as a very powerful way of integrating objects. As an excellent example, you can call anything that implements __call__, using the standard () syntax (I understand Ruby has a similiar concept).
I think the Ruby take on this, and my own feeling, is that this represents an unnecessary level of abstraction.
Why use len(array), which calls array.__len__(), when you can just call array.length() and skip the extra step? In a language that doesn't statically type variables, this doesn't make things any less flexible. "array" could be of any type, and as long as it has a "length" method, everything's fine.
Anybody who knows even the first thing about web-based applications knows you still have to do every bit as much validation on the server-side, regardless of what validation you do on the client-side, because the client can never be trusted to send back valid input. Client-side validation is a convenience for the client. Nothing more.
If Mozilla doesn't patent it, Microsoft will, and then they'll use it to shut everyone else down. I don't see anything wrong with decent organizations patenting good concepts just to prevent companies like Microsoft from having the same opportunity.