Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Same Diff (Score 1) 276

by snadrus (#49666587) Attached to: Ask Slashdot: What's the Future of Desktop Applications?

Browser APIs are gaining every advantage of Desktop APIs including APIs that are just landing. But they add to it:
- Instant update.
- progressive download: Download what you use
- Sandbox model: It's safe except the explicit permissions you give.
      -- This one is so essential, Mobile needed it to succeed with local installs. Desktops not having this is a huge step backward.

Desktop needs to gain these to keep up with web (except where they're unnecessary, like IoT). For performance, we've had unused capacity on most devices for a while.

Further, Desktop (all 3) has its own hazards:
- Shared libraries
- Special permissions for installation
- Old libraries based on poor ways of solving a problem
- Living-Dead APIs that shouldn't be used
- Unsafe languages you must interact with to get much of anything done.

Comment: Re:Native is here to stay, the web will fail. (Score 1) 276

by snadrus (#49666521) Attached to: Ask Slashdot: What's the Future of Desktop Applications?

Start-up latency has a web twist: you only download what you need in a well-behaved app. I've seen WebGL games where the textures landed after I walked into a room, sure that's undesirable but it shows that I didn't waste my bandwidth until I needed the resource.

HTML/CSS/JS is a documentation standard which is quite effective for document serialization. WebGL 3D isn't affected by it much.

Privacy is an interesting one. I'm in a company built around the theory people would care about privacy enough to switch in droves, and it didn't happen. Facebook proves that convenience trumps privacy well over 99% of the time. When it does, privacy-oriented cloud services are there with tools that can ensure even they can't read the data they're saving for you (barring an app update, which is true for local too).

Comment: Re:Cloud but hear me (Score 1) 446

Exactly!
Now in a business context this means expensing a business-class connection into your personal household (or a director-level person's), and having a small computer there with a something that's running redundant drives.

The only "untrusted" piece is the network itself (so, use SSH). A nightly Rsync should do. Place it in a house of someone who is already responsible for that data's security and you have no conflict of interest. Disk encryption avoids damages from a home break-in theft.

Comment: Smartphone 2.0 (Score 1) 292

by snadrus (#49401055) Attached to: EFF Fighting Automakers Over Whether You Own Your Car

Already answered. Smartphones are very programmable,
- except you don't have root (which is to ensure the system works like the OS maker),
- except the FCC-approved radio chip (to ensure you use public airspace inappropriately).

"Programmable cars" have been here since they put in radio tuners. The level of programmability should increase, but they should retain control of safety-critical operations.

Comment: Re:Maybe (Score 1) 303

by snadrus (#49400367) Attached to: Microsoft Engineer: Open Source Windows Is 'Definitely Possible'

In other words, they realize that the scale it tipped and new developers are questioning the value of education in .NET so Microsoft did the only thing they could to keep their domain-specific knowledge relevant: allow it to target Linux, iOS, and Android in the only reasonable way. Had .NET kept targeting Windows desktops and servers only, their base language would have been starved for developers in a few years.

Comment: Re:If you could run your own cable this would go a (Score 1) 208

by snadrus (#49398839) Attached to: Comcast Planning 2Gbps Service, Starting With Atlanta

I look at the FCC.
If everyone's home wifi equipment was a mesh networking system that interfaced with 10s of neighbors, then every side of that neighborhood would be a connection. This would all connect to "Central" City-based hardlines for faster routes around the world (because this most-resembles the roadway system, which is paid-for similarly).

The result:
- Cheaper prices (just the cost of peering with other cities).
- Faster Peering/Torrenting: Someone in-town has the file? Then it's just a network copy.
Competition would connect you to more fast-routes, not exclusive ones. Your choice to peer those are up to you (but would be the default for hardware).

Comment: Tiny Pieces (Score 1) 133

Open-Source software has a number of irreconcilable differences from closed-source software that makes comparison tricky:
  - Ownership
  - Rejection of low-quality code
  - No deadlines

A similarity:
There are more open-source libraries on GitHub in Javascript than any other language, and quite a bit of consumption of them. Most are built & maintained by one person. Lots of components are used to build an advanced website, but each is fairly replaceable.

My closed-source employer follows a similar process with each developer exclusively maintaining one or more tiny programs. Some of those were designed poorly to meet a schedule (by people who were let go). Now others (me) are creating replacement programs. Since each program does effectively very little, and it's well-documented for integration purposes, it's quite easy to replace entire programs outright that contain trouble. This gives us the same language freedom that open-source enjoys.
Further, it's a revolving door. Any program that's sufficiently devoid of "company secrets" is free to be open-sourced. This makes the company "dev-community focused" which helps hiring & retention.

To the systems programmer, users and applications serve only to provide a test load.

Working...