Having used GNOME 3.2 for a while, it actually does work pretty well, there are some annoying corner cases that either haven't been fixed yet, or where somebody experimentation seemed to win over common sense (like breaking standard alt-tab). But overall It Just Works, and I do believe it's much easier to understand and use for less tech-savvy users, which was the original goal I think.
There was a lot of complaining about the GNOME 1 -> 2 replacement too back in the day, but given some cycles, the rough corners were fixed and most people seemed to be happy. If you don't like being the guinea pig, wait a year or two.
Meanwhile, you can fix most of the issues with the awesome extension system they've got up and running. I think it's going to be interesting to watch that space over the coming years, it looks to me like it could completely change the way new good stuff is introduced to the desktop.
Did anyone actually click through to read the offering from Google? They aren't interested in everyone's data, they are interested in data from some to use for market research and rather than snooping it from all the Chrome users they've got, they are paying for it.
I can understand why someone wouldn't want to sell their browsing habits like this, I'm certainly wouldn't either. But if you've ever been at the other side of the table trying to figure out how to make a web site better for your visitors, you'll know that each individual is completely irrelevant. What you're interested in learning about is what people in general do and why.
For some reason, a lot of people have the mindset that engineers have to do everything as per the waterfall model, and that software engineering is all about process, methodology and code maintainability.
I think this is because the traditional methodology (or should I say Methodology) cult has branded itself that way for a very long time. I had a CS course on software engineering with a 800+ page "software engineering" book full of intricate ways of producing tonnes of almost completely useless documents and very little real-world advice on how to actually design and develop software and manage a software project.
What separates software engineers from hackers is that software engineers analyze the systems they work on, using computer science and mathematics.
And thinking critically about new ideas and their application. There are lots of fads and architecture astronauts in software development.
Both are totally legitimate forms of software engineering. But waterfall-style "engineering" is cumbersome, slow, extremely expensive, and tedious. If you love programming, pick a small company with an agile mentality. I've done both styles, and I don't ever want to work in a large software shop again!
I'm with you, except I think you're being too kind too the waterfall model. If you read Fred Brooks' The Design of Design he explains why the waterfall model is flawed and mentions that it was actually presented in one of the first papers about it as an example of how not to do things.
The main problem with it is that it does not allow any learning on either side of the fence.
Software quality: use Test Driven Design to ensure your code behaves as it should.
I don't think this is necessarily the best advice. It can make a lot of sense in some circumstances, but in others it's just a waste of time. You should try to understand the trade-off. I know there are some papers out there about it.
The important thing is that you won't know if you code is behaving as it should until the real users are using it. You need to link your sense of accomplishment to the happiness of the customers/users.
Predictable deployments: practice and simplify deploying your code for systems.
Any seasoned hacker would do this because any seasoned hacker has quickly found out that the repetitive task of deploying is a nuisance. You write a script to do it. Period.
Generalizing this idea a bit, as you go about your work, stop from time to time and think about what's the most annoying part of the projects you do and set aside time to see if you can find a way to fix that (setting aside time is the important part). Fixing things like deployment or integration testing or an API that turned out to be cumbersome to work with or finding a way to interact better with a customer who's a PITA can all make a big difference.
Of course, some problems are unfixable in the sense that they represent a trade-off, the lesser of two evils.
That's simplifying it. Lawrence Lessig in Free Culture has a deeper analysis. Remember as long as those people not paying would never have paid anyway, you are not loosing any customers, just gaining fans.
So you don't think she learned anything from this unlucky incident at all? How would you feel about being put on a list that guarantees you'll be harassed every time you board a plane?
All things considered, if a site scores high in search results because it has the most relevant results
The truth with these sites is more likely that they score high because someone is paying a lot of money for SEO, financed by the all the ads. Maybe it's easier to detect these sites by the ads than by the SEO techniques?
It doesn't matter how much better Firefox is on its own at memory management, in practice many people using Firefox are using it because of the plugins (otherwise they'd be using some other browser), and the plugin developers may not be so good at memory management.
Actually, the presentation addressed that. They're going to add a notice to known bad add-ons at the Mozilla add-on page (social engineering), and also add a basic leak test to things done by the reviewers.
Another way of explaining this is that with OLTP, you often just have the latest version of the objects, say your current products, with OLAP you often store everything. In a sense, old stuff (say old orders) isn't interesting with OLTP, since you're focused on the selling new stuff, with OLAP it is since there you're focusing on understand the operations of the company itself and the customer base (so we sold x widgets last year, but only y this year, why is that?).
Paraphrasing: "Adding tests to your code will require you a lot of maintenance. Every time you change your code, you need to change your tests. It's a never-ending process."
Not that I necessarily disagree with your point. I just think automated tests have gotten their fair share of hype at this point. They represent a trade-off, just like most other strategies.
I do agree with others that external documentation is just as if not more important than internal comments.
It's interesting you say that, because, with the exception perhaps of library code with a well-defined API, it's my impression that external documentation has a tendency not to be updated and expanded, and therefore quickly lose its value, hence not being such a great idea after all.
I know people here don't RTFA, but you could at least read the comment you're replying to in full. If these patents are hogwash and Microsoft is really strong-arming the vendors here, the system is very broken indeed.
That's of course speculation, but on the other hand why is it that we can't get to know which patents are involved?
Yeah, Microsoft Research is not R&D in the product development sense, it's research, like the thing your local university is doing. There's lots of good research coming out of Microsoft Research, but the question is whether any of it has anything to do with these patents. It would probably be jumping to conclusions to assume it has.
Slashdot Mirror
Having used GNOME 3.2 for a while, it actually does work pretty well, there are some annoying corner cases that either haven't been fixed yet, or where somebody experimentation seemed to win over common sense (like breaking standard alt-tab). But overall It Just Works, and I do believe it's much easier to understand and use for less tech-savvy users, which was the original goal I think.
There was a lot of complaining about the GNOME 1 -> 2 replacement too back in the day, but given some cycles, the rough corners were fixed and most people seemed to be happy. If you don't like being the guinea pig, wait a year or two.
Meanwhile, you can fix most of the issues with the awesome extension system they've got up and running. I think it's going to be interesting to watch that space over the coming years, it looks to me like it could completely change the way new good stuff is introduced to the desktop.
Did anyone actually click through to read the offering from Google? They aren't interested in everyone's data, they are interested in data from some to use for market research and rather than snooping it from all the Chrome users they've got, they are paying for it.
I can understand why someone wouldn't want to sell their browsing habits like this, I'm certainly wouldn't either. But if you've ever been at the other side of the table trying to figure out how to make a web site better for your visitors, you'll know that each individual is completely irrelevant. What you're interested in learning about is what people in general do and why.
Red Hat gave up on the desktop
Huh? They're still funding it. Red Hat developers are the main drivers behind GNOME 3 as far as I'm aware?
Have you had a look at Evolution? They used to position it as an Outlook competitor.
For some reason, a lot of people have the mindset that engineers have to do everything as per the waterfall model, and that software engineering is all about process, methodology and code maintainability.
I think this is because the traditional methodology (or should I say Methodology) cult has branded itself that way for a very long time. I had a CS course on software engineering with a 800+ page "software engineering" book full of intricate ways of producing tonnes of almost completely useless documents and very little real-world advice on how to actually design and develop software and manage a software project.
What separates software engineers from hackers is that software engineers analyze the systems they work on, using computer science and mathematics.
And thinking critically about new ideas and their application. There are lots of fads and architecture astronauts in software development.
Both are totally legitimate forms of software engineering. But waterfall-style "engineering" is cumbersome, slow, extremely expensive, and tedious. If you love programming, pick a small company with an agile mentality. I've done both styles, and I don't ever want to work in a large software shop again!
I'm with you, except I think you're being too kind too the waterfall model. If you read Fred Brooks' The Design of Design he explains why the waterfall model is flawed and mentions that it was actually presented in one of the first papers about it as an example of how not to do things.
The main problem with it is that it does not allow any learning on either side of the fence.
Software quality: use Test Driven Design to ensure your code behaves as it should.
I don't think this is necessarily the best advice. It can make a lot of sense in some circumstances, but in others it's just a waste of time. You should try to understand the trade-off. I know there are some papers out there about it.
The important thing is that you won't know if you code is behaving as it should until the real users are using it. You need to link your sense of accomplishment to the happiness of the customers/users.
Predictable deployments: practice and simplify deploying your code for systems.
Any seasoned hacker would do this because any seasoned hacker has quickly found out that the repetitive task of deploying is a nuisance. You write a script to do it. Period.
Generalizing this idea a bit, as you go about your work, stop from time to time and think about what's the most annoying part of the projects you do and set aside time to see if you can find a way to fix that (setting aside time is the important part). Fixing things like deployment or integration testing or an API that turned out to be cumbersome to work with or finding a way to interact better with a customer who's a PITA can all make a big difference.
Of course, some problems are unfixable in the sense that they represent a trade-off, the lesser of two evils.
That's simplifying it. Lawrence Lessig in Free Culture has a deeper analysis. Remember as long as those people not paying would never have paid anyway, you are not loosing any customers, just gaining fans.
Check out this TED talk.
Me too, it took 15 minutes, and it's actually fun getting in touch with people you only see on television otherwise.
Here's a link to the actual discussion on the HTTPbis mailing list.
So you don't think she learned anything from this unlucky incident at all? How would you feel about being put on a list that guarantees you'll be harassed every time you board a plane?
So yeah, same old arguments, the question is why are they not being addressed?
Eh, but they are? For instance, as far as I know, the U.S. is supposed to get out of Iraq?
All things considered, if a site scores high in search results because it has the most relevant results
The truth with these sites is more likely that they score high because someone is paying a lot of money for SEO, financed by the all the ads. Maybe it's easier to detect these sites by the ads than by the SEO techniques?
For a starter, don't run a link farm?
Fun fact. In Denmark, tuition is free, and you get a basic level of economic support from the government for up to 6 years.
It doesn't matter how much better Firefox is on its own at memory management, in practice many people using Firefox are using it because of the plugins (otherwise they'd be using some other browser), and the plugin developers may not be so good at memory management.
Actually, the presentation addressed that. They're going to add a notice to known bad add-ons at the Mozilla add-on page (social engineering), and also add a basic leak test to things done by the reviewers.
Another way of explaining this is that with OLTP, you often just have the latest version of the objects, say your current products, with OLAP you often store everything. In a sense, old stuff (say old orders) isn't interesting with OLTP, since you're focused on the selling new stuff, with OLAP it is since there you're focusing on understand the operations of the company itself and the customer base (so we sold x widgets last year, but only y this year, why is that?).
Paraphrasing: "Adding tests to your code will require you a lot of maintenance. Every time you change your code, you need to change your tests. It's a never-ending process."
Not that I necessarily disagree with your point. I just think automated tests have gotten their fair share of hype at this point. They represent a trade-off, just like most other strategies.
No explanation for you or for others?
I do agree with others that external documentation is just as if not more important than internal comments.
It's interesting you say that, because, with the exception perhaps of library code with a well-defined API, it's my impression that external documentation has a tendency not to be updated and expanded, and therefore quickly lose its value, hence not being such a great idea after all.
... why should the programmer ?
Because he or she's a pro?
Wait, you DON'T have a real, physical pinball table in your server room?
Sure! But not in 3D.
I know people here don't RTFA, but you could at least read the comment you're replying to in full. If these patents are hogwash and Microsoft is really strong-arming the vendors here, the system is very broken indeed.
That's of course speculation, but on the other hand why is it that we can't get to know which patents are involved?
Yeah, Microsoft Research is not R&D in the product development sense, it's research, like the thing your local university is doing. There's lots of good research coming out of Microsoft Research, but the question is whether any of it has anything to do with these patents. It would probably be jumping to conclusions to assume it has.