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

 



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

Comment Carrier Phones - RIP (Score 4, Informative) 198

There doesn't appear to be much of a reason to buy a carrier-bound phone anymore, especially Android.

  • Security updates are few and far between
  • Major OS updates are almost non-existent
  • Blocking of OS functionality (ex. expandable storage on SD), WI-FI calling
  • Vendor bloatware
  • And now, third-party bloatware
  • Little financial benefit (what little there ever was) in subsidization

Basically, if you want an Android phone that will remain supported, you almost have to go non-carrier Nexus

Comment Hubba hubba, hubba - who do you trust? (Score 1) 412

The whole concept of "store" in Windows 10/UWP and Android is a pain. The default Microsoft/Google store gets trusted by default. On Android (at least on my phone) you can't set up the Amazon store and delegate trust to it (i.e. anything that Amazon says is Ok is Ok with me). You have to disable security to install apps from Amazon, which isn't great. Microsoft is doing the same thing, including the awkward side-loading option.

Windows store does have an "enterprise" option if you are going to use UWP for internal enterprise apps, but you still have to have Microsoft review, which also isn't great.

In my preferred universe, Microsoft and Google (and Apple, for that matter) would allow me to set up trust to any application source (store) I want (including, of source, Steam). If the current model of application protection were applied to browsers, every website would have to get SSL certificates issues individually for each OS, because there would be no mechanism to delegate trust to Verisign, Thwate, Entrust, etc. Users (and enterprises) should be able to manage trust for non-OS related applications and files, which means that we need a mechanism to trust third-party stores.

Comment Re:What a mess (Score 2) 461

She didn't pass anything as first lady, that's not how it works. As part of the Obama administration, she did plug TPP pretty hard. But your point about Trump having a running mate who was for every free-trade deal made (including TPP), while making a major campaign issue out of how bad they are is pretty lame.

Comment Poor Post Title, Not-So-Severe Issue (Score 1) 97

The OFA outlines this issue. What they are saying is that because the Swagger is a JSON document, if you use a code generator that simply regurgitates its values without validation, you could end up with code executing in the context of whatever is consuming the API. The issue is with code generators, and not the swagger documentation .

An example they give as an attack on HTML is the following (with angle brackets instead of square ones, obviously):

"info": { "description": "[script]alert(1)[/script]",

I guess the idea is that you have used Swagger code generator to create code to call the RESTful APIs you are interested in. The code generator includes this description (which seems kind of odd) in the generated code, giving you an alert when a page including this code is loaded. They also give an example of attacking the "paths" property (which includes information on what URLs can be used to call specific APIs) which would execute code on the back end. I could see this being more a legitimate problem.

A few things though before we all freak out:

  • If you are calling APIs from a party you don't know and trust, you are doing it wrong,
  • If you are calling APIs without reviewing them and their documentation, you are doing it wrong. If you are looking at a Swagger document and somebody put in an PHP or Ruby injection attack, it will stick out like a sore thumb.
  • For vulnerability to be exploited that party you trust with your data will have to insert malicious definitions into their Swagger file, and include enough definitions to attack all of the platforms that code will be generated for.
  • Because Swagger is now an open specification (Open API), the code generators in question can be updated pretty easily,

Titles like ZDNet's "Severe Swagger vulnerability compromises NodeJS, PHP, Java" are gratuitous hyperbole. Slashdot's title is a little better because it at least refines the panic to "tools", but still not great. There is an issue here, but the internet is not going to go down in flames over this one.

Comment So What? (Score -1, Troll) 206

So what if Facebook has a liberal bias? They are a private company, they are not funded by the government, they can do what they want. How in the hell is this the US legislature's concern? They should get back to their duly appointed rounds of providing rim jobs to the NRA, getting down on their knees in front of the telecom/bandwidth providers and waxing the Bentley's driven by their overloads in the financial services industry.

Whores. Leprosy is too good for them.

Comment The ads themselves aren't the worst of it (Score 3, Informative) 316

The ads are bad enough, but it's the stupid behaviors that get put in to make sure that you are forced to watch the ads (think VOD from cable companies that disallow fast forwarding). Watch something half-way through and want to resume it later? Not only will you have to watch the ads, but you will also have to sit through the content you have already watched. This move will cripple the user experience and drive users to other means to watch their movies online.

Comment Three Dimensions? (Score 4, Interesting) 112

"I'd be managing a distributed team of developers all assigned to different projects." This isn't necessarily a three dimensions challenge, and you should keep things as simple as possible. People with multiple bosses will often please none of them. If there are not clear lines of accountability and definitions of success, your only hope of this thing not devolving in a complete fustercluck will be the coders who find your projects interesting and don't have families to raise.

You mentioned you "independent project managers". If you are thinking about the Scrum flavor of Agile specifically but have project managers you are likely doing something wrong. More important is product ownership. "Agile" development success largely depends upon decisions being made on a daily basis. If your product owners are not engaged on a daily basis directly with the developers (even when cross-timezone meetings are painful) you're doomed.

Find your local leaders, the people who get things done. You need people on the ground who understand the culture and trust you enough to let you know what is really going on. It will be far easier to build these relationships if you regularly travel and engage with them. Do not delegate this part of your job, you are not going to be able to cultivate your leaders over video conferencing. People behave very differently in-person.

Oh, and keep your staff off of The Register, which has devolved into a DevOps cheerleading site - nothing good will come of it

Comment No Worse Than Other "Incentives" (Score 1) 258

Having managed at companies where IT is a support to (i.e. not the focus of) the company, the handling of IT compensation, annual reviews, etc. is always painful.

  • Mechanisms for reviews, metrics, etc. are almost always handed down the HR dept, and are usually structured around what 80% of the workforce does ("we build widgets") and not for supporting roles (IT, accounting, etc.)
  • Bell curves, stack rankings, etc. are usually dictated and force you to name at least some of your staff as incompetent, even if they aren't
  • Raises, bonuses and such are usually allocated from a fixed pool ("we have "$X" budgeted for the department for bonuses, merit increases, etc."); and rarely reflect increases in the marketplace
  • At least a large company like GE can vertically advance people to get them decent-sized raises. At small-medium businesses, this tool is not nearly as useful.
  • It always seemed that the only way to get a decent sized raise was to work there for a couple of years, evaluate the market, and threaten to quit once you have successfully interviewed for another job that pays significantly more.
  • If you do happen to have an outlier that you want to fire, you pretty much have to catch them getting ready to rape a puppy, warn them about it twice, and then wait for them to rape a puppy, catch it on video, and then you can show them the door. It is almost impossible to say "your code is awful, your designs are rubbish, etc." and get new people in, even in states that are "at-will" employment. This does nothing for the morale of everybody else having to carry the load.

HR, like many entities in a company, are usually understaffed for what they are asked to do. They are constantly having to reshop benefits packages (especially medical insurance), organizing workforce morale opportunities (without spending much money) and dealing with the occasional case of sexual harassment, puppy rape, etc. The annual review/raise process is one-size-fits-all by necessity, and it usually works for nobody.

I kind of agree with the idea that annual raises do not meet their objectives (especially when they are small). What would I like to see? Maybe something like an annual bonus (meaningful in size), accompanied by review of salary every two or three years versus current market data ("we see that since we hired you, your salary has fallen on the lower end of the curve of developers similar to you, let's fix that"). As long as the work is interesting and the environment pleasant, I think this would be a more stable option for IT professionals.

Comment Re:Use Node for what it is good for (Score 1) 341

For better or for worse, a lot of this (esp. microservices) comes down to cost. In the "good old days" I could load a service, batch process, etc. onto a server in my data center that had the spare capacity to deal with it. Of course, in those same "good old days" I had to worry about things like fiber channel firmware, router OS updates, etc. and never, ever, had the resources to do that right. We always used equipment well past its depreciated book lifespan, and generally replaced stuff only when it broke. We very rarely got the budget to adequately address redundancy and fail-over.

The "cloud" largely absolves us of responsibility for dealing with firmware, failed drives, etc. Yes, sometimes there are failures, but anybody being honest about uptime (especially with AWS) has to admit it generally is a lot better than the average SMB data center. The big downsides are privacy and cost. Your data lives somewhere else, with what else you have little idea, but that's a pill that more companies are learning to swallow. A lot of companies use AWS as a glorified server farm, which is the most expensive way to use the "cloud". The platform-as-a-service stuff and now micro-services (Lambda) scale much more economically. For me, it helps to look at all of this kind of like the difference between building with Duplo and regular Lego bricks - you can do far more elegant designs with the smaller bricks, and you ultimately end up with stronger builds.

Comment Re:VB6 the Language wasn't the problem... (Score 1) 331

COM DLL hell was nothing compared to the hell that is .NET's DLL hell.

With .NET, at least you often (but not always) have the option of including the assembly DLLs with your distribution, without blowing up everything else in the destination system. You generally do not need to globally register (or rely upon globally registered) libraries. EntityFramework is an example. Going this route, though, make the software distributor responsible for providing application updates when the underlying libraries need updating. Both COM and .NET suffer from very poor versioning capabilities, but at least you're not forced to into continual regsvr32 tug-of-war with .NET.

Comment Use Node for what it is good for (Score 2) 341

Node is very good for processes that hit a database and/or file-system with "simple" manipulation. You will have to think asynchronously, and you will want to learn promises. Where it shines is when you have a lot of simple things to do during a method, and you can do those things concurrently. It's great for squeezing out every last ounce of CPU/core capacity - which can be priced at a premium if you are on "the cloud".

For web-hosting, you can use something like Express, and implement it with clustering to scale out to your server's capacity with regard to CPUs/cores. This gets very clunky, very fast, much more so than PHP or even ASP.MVC. It seems like a solution looking for a problem. I'd avoid it.

One of the better implementations I've seen of Node is in AWS. You can upload a Node package to their Lambda service, and trigger based upon a schedule, S3 (file) event or an inbound web call (via API gateway). It pretty much scales "auto-magically". But there are limitations. You have some utilities like Ghostscript available, but you are mostly limited to the version they have on their server images. You can include your own executables (by building them in an EC2 instance), but this increases your package size, load time, etc. If you want to use Node for a website, I'd probably limit Node's use to webservices (AJAX) for hitting the database and business logic; and drive your site's UI using a client-side engine (Angular, react, etc.). You can use it very effectively for back-end processes thumbnail generation, email notifications, etc.).

For "quick & dirty" websites, I'd probably avoid Node, unless you are going to drink the "cloud Kool-Aid" (especially with AWS Lambda); then Node might be a fit if you are going to craft custom sites where scalability and cost management are significant considerations.

Slashdot Top Deals

"No, no, I don't mind being called the smartest man in the world. I just wish it wasn't this one." -- Adrian Veidt/Ozymandias, WATCHMEN

Working...