Please create an account to participate in the Slashdot moderation system


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:or, maybe Google screwed up "ownership" (Score 1) 131

If Google had designed (? or something?) Android so that updating the base OS was something that could be pushed direct from Google instead of from each manufacturer's bollixed version of the system, there'd be no problem for any of us.

That may seem obvious now, but it's far from clear that Android would have succeeded the way it has if OEMs hadn't been allowed to differentiate their versions. That was (and is) something that's important to them, and they may well have decided that they wanted to do their own thing instead if Google hadn't given them the degree of control they wanted. Or maybe they'd have adopted Windows, since while it wouldn't allow them to customize it would have had the advantage of being from the then-biggest OS maker around.

It seems very likely that the ability of OEMs to customize was a core component of what made the Android ecosystem successful.

Also, keep in mind that the only way Google could really have kept OEMs from modifying Android however they like would have been to keep it closed. Personally, I'm glad that Google made the choices it did, not because I'm a Google employee working on Android (though I am), but because I've been an open source and free software advocate since before Google even existed. Android is far from perfect, and devices aren't as open as I would like, but I think the mobile software world is much better than it would have been without a F/LOSS mobile OS.

Comment Re:There's a simpler answer to this (Score 1) 131

Carriers would find a way around this. e.g. "you have to own the phone before you are eligible for security updates" T-Mobile does the "pay $20 a month" for a new phone, so you wouldn't really own it until your contract was up. That's why I think that "other" brands will start making real inroads into the market - BLU, Huwei, Xiaomi, etc. I have a BLU, and love it. Dual sim, unlocked, octacore, 2GB ram, gorilla glass, for $150. Why would I buy some $600 phone? As long as the manufacturers control the updates, I might as well get a good phone that I can afford to either root or replace in a couple of years.

Comment Re:Outrageously short service life for updates (Score 1) 131

I still think that two years of updates is outrageous forced obsolescence that is prematurely adding electronic garbage to landfills.

FWIW, it's actually two years of upgrades and three years of security updates on Nexus devices.

I'm seriously considering going back to an iPhone on my next phone upgrade, despite all the concerns I have about them too. They at least support their hardware for around 5 years.

At least they have done so in the past. Note that they've never made any commitment to that, so they could stop.

Comment Re:Batten down the hatches - a bubble's bout to bu (Score 1) 154

The central banks of the world are conjuring money out of thin air and using it to buy stocks

Cite? I'm not aware of any central bank buying stocks. The "quantitative easing" they're doing -- AFAIK -- is all bond purchasing, which means they're not buying ownership in real businesses, they're lending money to real businesses.

Concurrently, interest rates are artificially low

That's debatable. Without the actions of the central banks, we would likely be in a deflationary cycle. Assuming interest rates naturally adjusted accordingly, they should go very low, or even negative. Some of the central banks have gone to slightly negative interest rates, but they won't go nearly as negative as would naturally occur in a deflationary cycle. Instead, they're pumping money into the economy (via QE) to avoid deflation.

Comment Re:"More Professional Than Ever" (Score 2) 256

You are confusing contributing with leading the project.

Determining what code is written, what new features are developed, is leading the project. Not merging the contributions after ensuring the code is well written.

Linus leads from behind. After a feature is developed, he decides whether it will be allowed into the kernel. It's the same sort of decisionmaking process as in most development workflows, it just front-ends most of the work.

In most development processes, someone will decide "the product should do X", and they'll make some slides and pitch the ideas and the leaders will decide whether or not to pursue it. If they decide to pursue it then the developers will build it, debug it, test it, etc. The process is optimized around conserving a scarce resource, developer time.

In the Linux process, someone decides "Linux should do X", and so they build it, write all the code, debug it, test it... and then they'll send it to Linus, who decides whether or not to merge it. Same process, the difference is that the leader decides on the basis of fully-implemented code, rather than slideware. In the Linux model, developer time is not scarce and the process does not optimize for conserving it.

Comment Re:Users mostly part of the "used phone" market? (Score 1) 153

I don't know and there's no point in baseless speculation. I would guess it would be something like a security chip in the Nexus 5 isn't compatible with the new secure boot mechanism, but again, I have no idea.

No, it's nothing like that. There are some security-related features that are improved on the new devices, but those in and of themselves wouldn't block upgrades.

It's actually pretty simple. Google has committed to supporting devices for three years, and the Nexus 5 is more than three years old. If you really want to run Nougat on a Nexus 5, though, you can do it. Just unlock the bootloader and flash it yourself.

Comment What a long painfully joyful trip it's been... (Score 2) 256

I ditched Windows back in 1998 and installed RedHat 5.1. It was awesome! Then I upgraded. Wow, what a nightmare. Dependency hell. I struggled with it for a few years, but hung in there because I just loved it and had no interest in going back to Windows. Macs make my brain hurt.

Then along came Mandrake which took away some of the pain. That was great as well, really liked KDE. Upgrades were still painful, but much better.

Then I started hearing a lot about Ubuntu so I made the leap to Kubuntu 6.06. I went through about 8 in-place upgrades over time (minorly painful) until I finally things got unstable enough that I did a fresh install. Things were much better... but I kept having issues with KDE wigging out on me and pegging my cpu.

So I installed XFCE on top of Kubuntu. XFCE spoke to me - I realized all the UI flash didn't matter to me. I would flip back to KDE, but the problem kept happening and I was happy with XFCE. Eventually I heard about Mint around 2011, and had to try Mint XFCE - I have been there since. I have decided to not do rolling installs anymore, but I am configured pretty well to do full installs. I just installed over my Mint 17 XFCE release and was up and running on Mint XFCE 18 in about an hour. (my / partition is 55 GB and only uses about 12, and I have a separate partition for home). This was the smoothest linux system update I have ever had - even no issues with the Nvidia proprietary drivers!

Installs aside, my Linux system does everything I want it to do. Seeing all the various applications on it grow and blossom, and really cool things like bootable distros to embedded linux to mini systems to android. It has really been great to see it all flourish.

At work I use Windows 10, and I get by. But it brings me no joy. At home I run Linux, and it brings me joy. Thank you to everyone who has contributed to it.

Comment Re:Do we nned it? (Score 2) 153

what benefit will that give when most of the energy is consumed for the display?

That depends on your usage model, and on your display settings (most importantly, how long the screen stays on when you're not using it).

For most people the display is the biggest single consumer of power, but the combined radios (cellular & Wifi) are almost as big, and radio + CPU power consumption is considerably larger than display consumption. Doze mode conserves radio and CPU power, and for most people does provide a big increase in battery life.

This isn't the case if, for example, you spend a lot of time playing (CPU-light) games or reading books or other uses that keep the screen on for hours but don't use a lot of CPU or data. In that case, Doze mode won't do you much good because you're keeping the screen turned on all the time.

you'd still only see a 25% battery time increase at best.

A 25% increase is huge. The way batteries are sized in phones, most users get around 12 hours or so. Say, 6AM to 6PM. If you increase that by 25% you now get 15 hours which is very close to a full day. Make it 30% and you have a device that only needs to charge while the user is sleeping, in most cases. Given that most smartphone users have already arranged to plug their phones in at various points in the day (while commuting, etc.), even a 20% increase in many cases is enough so users find that their phone always has plenty of battery.

Comment It's the efficiency mindset... (Score 1) 504

I'd argue that very few people's productivity is measured in how efficient their file operations are. It's sort of like believing you're going to be vastly more efficient as a programmer if you memorize a bunch of keyboard shortcuts or type 60wpm instead of 30. Unlike the movies [], programming isn't about how fast you type.

I think it's more about learning how to work efficiently, and keeping an "efficient" mindset in whatever you do. Example: I use pine for my email, I have since around 2000. I use fetchmail to pull in a few accounts locally. If I want to check my email, it's faster for me to ssh to my home machine and check it rather than scan across several emails on my phone (I do use K9 to pull them into one app though). Now, if I want to view and attach pictures to emails, or look at attachments, then a GUI is better. But most of the time I am just reading the text and ssh/pine is much more efficient.

Another example: at work someone on my team was trying to generate a 2 million row csv file for testing. She was trying to do it in Excel, and it was very cumbersome and slow. Using an example row, i created a script that was able to generate a million rows in about 5 minutes. Then I used a couple of other tools (sed/cat/vi) to copy the million row file, modify it, and cat them back together. She had her 2 million row csv file in about 15 minutes. She was amazed. Since then I have worked on several other large files like this because people think they have to use Excel to view csv files. And vi kicks notepads ass in editing.

These are just two examples of doing something efficiently. Yes, it was comfortable for me to use these things, but there was no other good solution for this particular problem because people were locked into what they knew. Back on topic, I can certainly use other desktops, but I moved to XFCE many years ago when KDE kept eating my CPU for some unknown reason... and I have simply grown to prefer it. MintXFCE is my sweet spot now, and I don't have any plans to switch.

Comment Re:Stop chasing the shiny (Score 4, Insightful) 160

Now we use them as VR systems, which will drive the need for faster phones with better displays and better positional tracking for years to come.

Is this a need, or is this a want?

That question is irrelevant. If I want to have a device that does something, and I want it enough to shell out the money for it, why in the world shouldn't I?

Your whole premise is that people are somehow wrong if they want a shiny new phone every year. Who are you to tell people what they should want?

Comment Re:Hmmm how bad could it be? (Score 4, Informative) 515

Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay

Except... it wasn't a systemd bug at all. Per comment #16:

Ok, with everyone confirming that the systemd patch is not required, I am closing the systemd part of the bug as 'Invalid' - let's only concentrate on the dbus part here. That being said, I would not like to release a new patch for dbus downstream if the patch hasn't been fully reviewed and approved upstream. In this case I would propose to wait a bit and see if a finalized patch will be available.

Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.

Slashdot Top Deals

"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry