Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:We are back to square one (Score 1) 212

So are you proposing a consumer pay-per search model, or a monthly subscription? Or is the search company supposed to be taking money from the sites who'll pay for higher rankings? Mapping probably only makes sense as a consumer subscription service.

Mapping companies could make money from advertising (cf. Mapquest) or subscription fees (other GPS navigation services). What they can't do is compete against Google Maps and Google Maps' backend, both of which are completely subsidized by Google's vertical monopoly but don't display ads on their own and couldn't survive *solely* through the apps they do display from AdWords independently. Using the market-dominant position in one industry (ads) to subsidize their position in another industry (online mapping), keeping prices (subscription and/or annoyance) artificially too low to make it worthwhile for anyone else to try to compete... is classic monopoly behavior.

Comment Re:While warehouse-based factory farming. . . (Score 1) 131

1. food deserts are by and large a myth

2. if there is a food desert, using that space to sell food (grown elsewhere) 365 days a year is a better solution than spending 360 days farming for 5 days of produce.

Mod parent up on accord of both comments.

Outside of, perhaps, Detroit, "urban farming" doesn't make sense as a purely economic policy. If you want to keep people out of trouble, or increase vegetation in the area, or improve agricultural skillsets, fine. But "localvores" are eating locally because they're willing and able to pay for inefficiently-grown food by choice. If you need food in the area, you can get it there cheaper by transporting it from somewhere it's cheaper to grow it. Period.

Comment Re:We are back to square one (Score 2) 212

In your hypothetical breakup, only the advertising company stands a chance of surviving. Advertising is the only Google (sorry, Alphabet) company that actually makes money, and it subsidizes all of the others. Conversely, all the others slurp up user data to enhance the functionality of the advertising company. So post-breakup, the advertising company would be crippled, starved of the data that makes it valuable, and all the others will die from having zero funding to run them. So congratulations, you just killed Google.

Well, yes. That's the point. One of the largest reasons for breaking up huge vertical monopolies is that the cost of entry for other participants is too high because the monopoly can subsidize one side of the business with the others. Can anyone else create a viable mapping, searching, or other business competing with them? No, not really. The only competitor they have in any of these is in Smartphone Mobile OS -- which is a duopoly with Apple.

Google needs to be broken up, for the good of the tech industry and of the country as a whole.

Comment Re:We are back to square one (Score 2) 212

Yeah, that worked out so well for the phone companies. Oh wait, they've all merged back together again. Breaking up companies because you think they're too powerful are the thoughts of short sighted people.

There's an argument to be made that physical high-capital network infrastructure creates a natural monopoly, which ultimately ends up regulated.

But Google warehousing "all the world's information" and vertically integrating every aspect of this into myriad levels of myriad electronic devices is not the same thing. That's what MS was saying back in the '90s (private, in-house Windows API access by the Office and IE teams was a net benefit) and the industry wasn't having it.

Comment Re:We are back to square one (Score 4, Interesting) 212

We survived the IE near-monopoly and ended up with a nearly-standardized web platform instead of the incompatible mess it was before

Sure, but it took twenty years, and everything is organizing under Google's banner. Even Firefox is practically indistinguishable from Chrome these days, and will be entirely so once they discontinue support for legacy plugins/addons. So instead of having Microsoft dictate terms through outright monopolization of the market, we're allowing Google to dictate terms because...... why? We trust them?

This is a matter of faith; we've traded monopoly for theology.

This is exactly it. Only I fear that this time the technical populace somehow thinks this is a Good Thing. Control by information companies is not any better than control by software companies, and in fact is almost certainly far worse for a whole host of Orwellian reasons.

We fought and fought and fought to remove IE's monopoly, but the biggest work overall was done by Apple. Remember when we wanted to break up Microsoft into an Office/Apps company and an OS company? It's hard to imagine that we shouldn't break Google up into an advertising company, a tech hosting company, a search company, a browser company, a mobile OS company, a cloud computing company, and half a dozen other distinct entities. But this time the Bay Area is fully behind unified, Umbrella Corp, control because "it's easier".

Read a book, guys. Learn your history.

Comment Re:Next you'll be outraged that microsoft donates (Score 1) 103

Because directly donating the product doesn't get you a tax break. Donating cash, and then requiring that the funds buy your product gets you a tax break on money you never *really* donated.

Mod parent insightful. OS licenses are free and are exactly why education licenses can be given out rather cheaply to begin with.

A "donation" to purchase my own products is just money laundering.

Comment Re: Super safe Linux (Score 1) 164

Is that really so? I've always heard that many or most of Linux users never reboot their systems and I felt like a noob for doing so.

Outside of a basically a kernel or glibc update, you don't need to reboot your system to make anything "take effect" unless you're using Linux on the Desktop, and why in God's name would you do something like that? You should, however, pay attention to security updates and make friends with 'lsof' for the most critical libraries. There's a yum plugin that can help identify things that might need to be bounced following an update, but it's not automatic by default because that's really something that an admin should be deciding on re their site's policy.

It's a good idea to reboot every once in a while just to make sure you still *can*, but that's more an operational engineering decision (better to trace back 2 months' worth of changes than 2 years) than a software decision. Recently, there have been enough kernel security updates in even the stable distros that simply applying those will take care of your safety reboot.

Comment Re:Init alternatives (Score 1) 338

In my experience, Slackware is a lot (very noticeably) faster than Fedora on the same HW. I don't know whether it is due to systemd or SELinux or something else entirely, but if you need raw speed, then you seriously should consider going back to basics.

Fedora would have been well served by following Debian's DashAsBinSh project back in the day. Post-kernel boot times might have been cut by up to a half or so, thus dulling the argument for systemd to begin with.

Comment Re:Init alternatives (Score 1) 338

It isn't so much that "old is bad" as that the new is more likely to have been designed with modern paradigms in mind. Despite your dismissal, parallelism in particular is important, especially as Linux has taken a role as the embedded OS of choice for smart devices and cheap laptops.

Linux was succeeding quite well in the non-RTOS embedded space and with cheap hardware long before systemd came around. And an embedded device (aka, an appliance) is precisely where you want the MOST deterministic functioning. You don't just randomly through a bunch of parallelized shit in there and hope systemd all figures it out for you.

The fact remains that the previous init harness was perfectly reasonable. People that needed service management, socket launching, and other functions had options in daemontools, inetd/xinetd, runit, and myriad other tools out there, while rc (on BSD) or the chkconfig-controlled symlinks in rc.d gave structured sanity to the set of deterministic instructions a machine needed at boot.

Systemd's writers forcefully shoved all that aside in favor of a one-size-fits-all strategy that people had to accept whether they liked it or not, and once it was in place, they did everything they could to burn the bridges back to other paradigms.

Comment Re:Based Gentoo (Score 1) 338

yay gentoo! Its very easy to avoid that systemd garbage. I'm not just bandwagoning here, I have to setup RHEL7 for a very large company because they wanted to stay with RedHat. It was hell on wheels. RHEL7.1 was a slight improvement but still not enough to ever consider it again.

I would kill for a systemd-free rebuild of RHEL, but it doesn't seem like there's enough of a push to be able to make it happen with some sort of plausible enterprise ability. It wouldn't be that hard -- basically take RHEL7 and stick RHEL6's initscripts and startup system onto it -- but it wouldn't be "EL7", which is important.

A systemd-free version of Fedora is tricker, if only because LP and friends have succeeded in burning as many bridges as possible within the base install away from any other init paradigm. Good job, guys. I hope you rot.

Comment Re:Reading the headline... (Score 1) 53

Oh sorry, I ddin't know that only RedHat used systemd... They don't so the constant moaning about it is getting rather tiresome.

They aren't, but RH corporate inexplicably pushed it despite greybeards thinking moving wholesale to an unproven system with a leader with known issues was probably a bad idea.

Ironically, systemd solved problems that were mostly already-solved in RH-land, which is the big reason for the pushback ~2014 when it finally hit EL7 and enterprise admins had to actually care about it. (Boot speed? Please. Could have gotten a lot of that by mimicing Debian's use of DashAsBinSh. Virtually everything else other than cgroup management already had better discrete tools for management in the ecosystem.)

I tend to think systemd's adoption was just a classic case of organizational disaster, pushed by a FreeDesktop team with an agenda and myopia, and project managers with more faith in developers than the sysadmins who actually run the product. But "proprietary complexity on top of open source" is another explanation, given how simple-to-grok shell scripts were replaced with a technically-OSS 100K LoC mishmash of non-deterministic spaghetti.

Slashdot Top Deals

You can not win the game, and you are not allowed to stop playing. -- The Third Law Of Thermodynamics