Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Learn to Build 14 Websites with 28 Hours of Instruction on HTML, JavaScript, MySQL & More for $14 ×

Comment That's what the law says (Score 1) 147

He probably shouldn't be allowed to sue for that much, but then large rightsholders shouldn't be allowed to sue for the ridiculous amounts they sue for either. No matter, whether he should be allowed to or not, the law says that's what he can sue for since they infringed on his copyrights. Those are the rules the big corporations and rightsholders made, I don't see any reason why this photographer shouldn't play by them.

Comment Emojis are useful, but Unicode goes too far (Score 4, Insightful) 226

The original set of emojis worked nicely for incorporating emotional and attitude markers into otherwise emotionless text. I think we do need something like that in Unicode. The current set, though, goes way too far beyond that and needs to be mercilessly pruned back. Unicode is not supposed to be a way to incorporate every single image anyone could want as a single character. Trim it back and use images for images. To quote someone, "If you're trying to design a hammer that can turn screws, it's time for you to put the hammer down and go get a screwdriver.". OK, it's not an exact quote, but I can't do justice to the interspersed expletives in the original.

Comment Experience is required (Score 3, Interesting) 559

I've experienced the bias against older tech workers. I've also seen the results of that bias: work that would've gotten a failing grade even in the college courses I took, let alone at some of my employers. There's a considerable advantage to having been there, done that, can see how current problems match previously encountered problems and what methods already exist to solve them. To give an extreme example, traditional Web applications (most logic on the server, Javascript in the client is used primarily for input validation and display formatting) mirror very closely the flow of ancient 3270 workstation "green-screen" applications: the server sends a block of display and validation instructions to the client, the user enters the data without interacting with the server, the client sends the completed form back to the server as a single block for processing. The same flow held for the forms applications I build for DEC VAX/VMS in the 80s. And many of the tricks developed to maintain session data across requests for web application are the same tricks we used for the same purpose way back when. I can see the same pendulum swing at work as well: 3270 workstations gave way to interactive terminals (where the application could directly interact with the user), which gave way to forms applications, which gave way to thick clients (PC applications that accessed remote servers via various protocols), which in turn gave way to Web applications, which are now giving way to thick clients again (this time Javascript framework applications running in the browser accessing remote servers via XML/JSON and RESTful interfaces). That perspective gives me a big advantage in knowing where to go for things that already exist and have had all the kinks thoroughly worked out that I can apply to the current problem, rather than having to work solutions out from first principles or copy-and-paste code from StackOverflow as a black box as many of the younger developers do.

Most of the bias I attribute to a mistaken belief that "old" = "unable/unwilling to learn". Some of that belief probably comes as a reaction to the normal skepticism older people have to the latest "silver bullet" sales hype. We've seen those fail to live up to the hype time and time again, someone who's only been in the business 5 years and who hasn't maintained a single application through many update cycles hasn't gotten the first-hand experience with the fallout. It's not that the shiny new tech isn't good, but the salesman is probably over-promising to try and seal the deal and I'd prefer to find the gotchas in a test project rather than by having production fall over.

Comment Re:Maybe not peak, but a plateau (Score 1) 197

For AR I don't expect the phone to be the display. As I said, something like Google Glass which uses the phone as the processing and communications unit and simply displays on effectively your entire field of view. No need to bind the phone permanently to the display, because displays will improve (just like right now we don't bind the phone permanently to a headset, we connect them via Bluetooth and we can replace the headset with a better model without needing to replace the phone in the process).

Comment Why would people be lazy? (Score 5, Insightful) 856

The whole idea that people are inherently lazy and won't work without being forced to always puzzled me. Most of the people I know want to do something productive, but more often than not it's either not something they can get enough income from quickly enough to be able to drop their day job and start doing it full-time or it's not something they can get enough income from to keep the bills paid. Give them a guaranteed basic income and they won't sit around doing nothing, they'll start doing what they want to do (instead of the day job they have to have because it pays the bills).

And on the flip side, what does Donald Trump do exactly? I know he's rich and considered successful, but what work does he actually do? Or Kim Kardashian? It always seemed to me that the more successful you were, the more well-off you were, the less actual work you appeared to do each day. I know there's research involved in say running a major investment fund like Warren Buffet does, but he doesn't do the majority of it. 95% is delegated out to subordinates who do the legwork and write up the analyst reports, Buffet himself just goes over those reports and makes the final decisions. It's something only he can do, but he's not spending 40 hours a week nailed down to a desk poring over corporate reports and newspaper articles and stock trade data, running spreadsheet calculations to figure out what's behind the stock movements and what's likely to happen in the future.

To quote a mill supervisor, "I don't want the industrious guy who'll clean up the mess with a smile. I want the lazy bastard who'll figure out how to stop the mess from happening so he doesn't have to clean it up all the time.".

Comment Maybe not peak, but a plateau (Score 4, Insightful) 197

I don't think we've hit peak smartphone, but we're at a plateau. The next steps will be three things:

1. Reduced cost and improved durability, bringing smartphones to those areas of the world that currently can't afford them.

2. Improved battery life. That's going to come from battery tech, not the phone side.

3. Augmented reality. Not virtual reality, but something like Google Glass that can use the entire surface of the lens as a display instead of just a small chunk in a corner.

Comment Reuseable K-Cup insert (Score 4, Informative) 299

There are inserts that fit the Keurigs that you can fill with your own ground coffee, then empty after it's brewed. I'd love to use them, it'd give me a wider variety of coffees. The only problem is that none of them seal properly, water and grounds come out the top and make a mess and the leakage interferes with the brewing. If Keurig really wanted to solve the problem, put the research into modifying the MyK-Cup so it seals properly and the water flows through the grounds rather than off the top and through the open mesh screen.

Comment Re:Fixable by phone-side installation prompt (Score 1) 48

The idea is that it won't matter whether you have 2FA turned on or not, you've already authenticated to your Google account and your compromised browser can then use it's access to that account to push the malicious app to your phone and activate it. 2FA can't protect you from that because the malicious code starts after you've handled all steps of the authentication for it.

Comment Fixable by phone-side installation prompt (Score 2) 48

Fix should be simple: when an app's installed remotely from the browser, queue the installation and put up a notification asking the user to confirm the installation. Installation doesn't proceed until the user responds affirmatively to the prompt (if they respond negatively, the installation's de-queued). The authors are right, though, that the more tightly you integrate the browser-based services with the phone the less you can depend on the separation of the two for security. What's different here is that it's showing that tight integration between Google's services and the phone affects vendors other than Google.

Comment Re:many were sold retail; no provider access requi (Score 1) 115

That's strange, because the manufacturer says there are no firmware updates available for the SB6141 (or any of their other cable modems). It's possible to update the firmware of the router portion of their combined products, but that update doesn't touch the cable modem portion. Plus seeing as how the very first thing the cable modem will do after it establishes a connection to the head-end is check it's firmware image against the head-end and download and overwrite if they don't match...

Comment Re:many were sold retail; no provider access requi (Score 2) 115

Yes, there is. DOCSIS doesn't permit user updates of the modem's firmware, because that would allow users to bypass limitations set by the cable provider based on what service they've purchased. Only the cable head-end can download firmware to the modem, so the ISPs have to add the fix to their firmware images and deploy them to the modems. Yeah, I know, but the network design treats the modem as a part of the cable network and not as an end-user device like a router would be. Just remind yourself that the cable network ends at the Ethernet jack on the back of the modem, not at the coax outlet on the wall.

Comment Re:Change app identifiers (Score 1) 77

The developer themselves. It's already part of the process of transferring an app from one developer account to another. Google just has to modify the server portion to automatically change the identifier as part of the transfer process.

If the developer set up a separate Google account for their developer account and they're transferring everything, they can just transfer access and in theory Google would be oblivious. In practice however the transfer involves things like changing the merchant account to use the new owner's bank accounts and credit cards, granting access to new individual Google accounts and closing down the access by the previous owner, that kind of thing. Google's tech should be good enough to flag that kind of activity when they haven't been notified of the account changing hands and send an inquiry. One addition to the terms of service, saying that transferring the actual Google account without notifying Google is grounds for suspending the developer account and all apps associated with it until the matter's been resolved, and it becomes very much in the interest of the buyer to make sure the notification happened. Even something as simple as tying an organizational account to an "owner" account (eg. you can set up a separate Google account to link the developer account to, but your personal account gets listed as "owning" that separate account and retains permanent control over it) and treating any transfer of that link to a different account as a change of ownership would probably work 99% of the time. The buyer probably wouldn't go for the seller retaining total control and the ability to kick the buyer out at any time, and the seller probably doesn't want to lose their personal Gmail and other services tied to their personal account.

Slashdot Top Deals

"Only the hypocrite is really rotten to the core." -- Hannah Arendt.