Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment Re:True (Score 2) 247

No, but he's trying to put the good PR spin on things.

How about this one to start.
http://www.latimes.com/news/la-na-gatesx07jan07,0,2533850.story#axzz2jXU69lfS

Basically, he does humanitarian work to the locals, but is a large stake holder in the factories that are making the locals sick. Because he's "helping" them, he's the good guy. Because he's only a large stake holder in the factory, he's not the bad guy. He brings in more money from the factory than he puts out to help the locals.

Profit/Loss. If you bring in $100M, and you pay out $20M, and look like the good guy, you're doing it right, as it's still an $80M profit. Since you're dumping the $20M in to "help" the people, the locals won't complain.

If he had more loss than profit, he would simply cut ties to both sides. It's not worth it.

Comment Re:True (Score 0) 247

There's no room in business for humor. No good business person makes a decision without calculating their potential profit and loss (or risk/benefit, if you prefer those terms). If you don't understand it, I'd hazard to guess that you've never been involved in senior business decisions for a multimillion dollar company.

Comment Re:True (Score 0, Flamebait) 247

It's a very obvious capitalistic endeavor.

Every person that dies is one less customer. You don't have to be Internet connected to be a Microsoft customer.

Facebook, on the other hand, requires Internet connectivity. Every person that doesn't have Internet service is an untapped customer.

Comment Not even then... (Score 1) 365

A lot of people don't even like wearing watches, I can't imagine people going for full-on bracers.

Either things are going to stay pocketable or some sort of augmented reality solution are the things I could believe. If I were a betting man, I would bet that pocketable will continue to rule the day.

Comment Re:Canonical might suck... (Score 2) 362

The problem is that some of the difficulties are by design. journalctl and systemctl are actually pretty straightforward to use. However, when things go off the rails, it's much harder to cope with than a system that retains plain text logs at the core. The argument that journalctl can give you plain text rings hollow when the tool is hard to get to (system had catastrophic failure and you are on the wrong end of a crappy connection but have a random system nearby that can peruse data. Lennart would call this a convoluted case, but it comes up surprisingly often. Meanwhile, having journal do plain text file alongside the binary file would neatly address a lot of the criticism without a whole lot of downside, but it's almost a religous objection to plain text logging rather than practical concerns keeping it soley the domain of syslog.

Comment Re:This is about products, not components (Score 1) 42

The old-school thinking was they failed to protect their intellectual property, and lost market share to competitors who copied their design

I don't think anyone significant believed that. Even IBM had long acknowledged that they thought the PC clones were the reason for the amount of volume they got. They knew long ago that thanks to that they got a decent chunk of a massive market instead of 100% of a pathetic small market (also, getting a decent chunk of change from all the clones that had to license a lot of patents, it's not like IBM let them 'steal', they licensed the relevant patents). IBM didn't plan that in the beginning, but they realized relatively early on that is was a blessing rather than a curse.

Comment Re:Canonical might suck... (Score 4, Insightful) 362

So one prominent example is a push to discard syslog, but at the same time rejecting any suggestion that perhaps it might be nice if the same plain text that journalctl can produce be produced as a matter of course without syslog assistance.

Yes, journalctl has more readily accessible nice filters and faster performance. The issue is that the vast majority of people didn't ever need them and made due with grep and friends. Yes it's not good stuff to build a high-end solution out of, but by the same token journalctl power is more complicated to use.

Getting early boot messages would have been a straightforward thing to do in syslog land, it was just that no one bothered. It was a good thing to add, but generally either things work fine and you don't really care much about the early boot logs, or it fails to get root fs going in which case the logs from that time won't make it to the root fs hosted journal anyway.

I don't like the linux distros of today because they are largely reimplementing much of what people ridiculed microsoft for in the 90s (binary configuration, binary logs, more complex messaging model). While it is true that generally the details of the implementation are defensibly better than microsoft did, the differences are largely academic to the vast majority of system administrators. Vast majority sees opaque binary blob that is useless without a very close match in distribution to provide tools to analyze. Even when things are humming along fine, things like dbus provide capability in a nearly impossible to explore manner. Even with all this complexity, my linux server experience is no more useful than it was 10 years ago from a managability standpoint, but I've had to jump through hoops to try to track the complexity as it emerged bit by bit without a lot of nice capability to come along for the ride.

Slashdot Top Deals

8 Catfish = 1 Octo-puss

Working...