Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment: Re:For all of you USA haters out there: (Score 1) 258

by firewrought (#48933561) Attached to: Why ATM Bombs May Be Coming Soon To the United States

And do you suppose the bank's employees pay for the fraud out their own salaries? Of course not! The cost of fraud is paid by their honest customer's banking fees

The cost is paid for by some combination of shareholders, employees, customers, and insurers. You can't really say what that combination is. If you magically eliminated all ATM thefts/fraud, most of that benefit would go to either shareholders or top-level management. However, if the labor market were tight, that benefit might go to higher salaries for ordinary employees. Then again, if competition is fierce, the savings might be used to lower fees or pay higher dividends on interest-bearing accounts. Perhaps something more complex would happen, like hiring additional programmers so more work process could be automated, thereby resulting in layoffs for other personnel. All of these outcomes have more complicated second level effects, since they would ripple through the economy at large.

What you can say is that we as society pay at large, since the damage to the machine/building is a net loss for humanity, and the effort of participants (police, bank personnel, ATM designers, and even the burglars themselves) could have been better spent on their next best opportunity cost. (The one exception might be if these were subsistence burglars, in which case the overall cost to humanity can be harder to calculate.)

Comment: Re:What are the practical results of this? (Score 2) 117

by firewrought (#48933297) Attached to: FCC Officially Approves Change In the Definition of Broadband

ISPs can no longer use false advertisement to try and trick ill-informed consumers (ie. grandma) into paying for garbage.

Easily solved:

BUY NOW!! Super-fast-ultra-speed internet** is available in your area!!

**Up to 1Mbps or beyond!
(And oh yeah, we'll still hijack DNS NXDomain responses, throttle Netflix/bittorrent, keep connectivity records, and spy on your traffic w/o a warrant.)

Comment: Here's a great idea... (Score 1) 213

by Lodragandraoidh (#48928627) Attached to: Anonymous No More: Your Coding Style Can Give You Away

You can have/use this idea for free:

Before a system will build said code, have the build system verify the code not only by the public key/code hash, but as a secondary method - the code fingerprint of the author in question.

This turns a creepy idea into something worthwhile.

Comment: Re:Open source code is open for everyone (Score 1) 208

by firewrought (#48928495) Attached to: Serious Network Function Vulnerability Found In Glibc

Do they? Do you have data to back this up, or are you just guessing? Because from where I'm sitting, it looks a lot like the hardest security problems are the features you expose to users.

If you don't have to have any features, then yes, you can make your software very, very secure. :-)

The CWE publishes a list of the Top 25 Most Dangerous Software Errors which aims to "list of the most widespread and critical errors that can lead to serious vulnerabilities". You'll notice CERT tags their vulnerability announcements with references to the CWE when applicable.

Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.

You contradict yourself at the end of the paragraph and try to come up with a reasonable substitute.

No contradictions... knowing how stuff work is a training/educational goal (for programmers and those who teach them). Not having to know how stuff works is a design goal (for language creators, API writers, and designers in general). The former gives you insight, the latter gives you leverage.

Comment: I'll let you know when I've met one... (Score 1) 206

by Lodragandraoidh (#48928487) Attached to: Ask Slashdot: What Makes a Great Software Developer?

I have yet to meet a really competent programmer. I don't consider myself much beyond capable - but I have too many flaws in my output to be considered really brilliant.

I have worked with or dealt with the output of other programmers who's performance was egregious - most egregious was the contractor who's naive use of a commercial java framework managed to produce the effect of a memory leak in java (e.g. hamstrung java's built-in garbage collection mechanism).

Experience has taught me practical measures of quality programmers in no particular order:

1. They must know how to program at the most simple level (e.g. competency in structured programming in C would be a good starting point - a basic understanding of LISP programming a plus) before tackling more complex programming tasks. I get the sense there are a lot of cut-and-paste programmers out there who really don't understand what the underlying code they are creating is actually doing.

2. Have an innate ability to focus on simple solutions, rather than being clever. KISS principle must be understood and brought into every design decision from the start. That is not to say there are no complexities, but understanding what is simple given the problem at hand - some simple things are complex when compared to other systems - and having the ability to avoid needless complexity.

3. Literate - must be able to not only communicate effectively externally - but also their comments in code should illuminate the subject matter in a clear, concise manner. Ideally should be able to get workable technical documentation straight from their comments - via doxygen or the like (perldoc, pydoc etc).

4. Their code must be maintainable and extendable. If an average programmer cannot maintain the code, and is required to rewrite the system from scratch - then you have failed as a quality programmer. Change is inevitable - how resilient your system is to change is a measure of your ability as a programmer.

5. They must understand a lot about technology outside of the world of their application. Their application will live in a world of networks, machines (physical and virtual), storage systems, communication protocols, and APIs - they must understand the implications of software design choices given a set of environmental requirements. The best programmers not only know how to code up systems, but also how to give advice about what their systems will be capable of doing given the environment, or lack thereof - and act upon that if it is possible to adjust via changes to software alone (e.g. choosing multithreading/multiprogramming design over single thread of execution).

6. They must be able to create secure code. If the company they work for doesn't produce a guide to that, then they should develop that on their own - and live by it - and consistently improve it. If they are using frameworks/libraries written by someone else, they should audit or test it to be sure the underlying implementation is secure.

7. Must be able to get along with others and work as part of a team; ideally if they are really a quality programmer, I would expect them to also mentor and share their ideals and capabilities with their peers to bring everyone up as much as possible. Quality programmers are not primadonnas.

That's it from my standpoint.

Comment: Re:Open source code is open for everyone (Score 1) 208

by firewrought (#48925473) Attached to: Serious Network Function Vulnerability Found In Glibc

Hey, if your point is that too many PHB's and programmers think "managed" is a cure-all, I won't stand in your way. What I'm saying is that managed is a huge win for security.

The hardest security problems to solve aren't the overflows, it's the features given to users.

By contrast, the most common security problems are any situation where you silently expect the programmer to manually preserve some invariant (e.g, never allocate memory without a plan to deallocate it, never deallocate if anything else holds a pointer to it, never write to a buffer without checking bounds, etc.). Managed languages eliminate C/C++'s largest (and most critical) attack surface.

Now sure, I agree that they don't eliminate all attack surfaces. Security is hard. Java/C# have their own "manual invariants", such as always escaping/parameterizing SQL. ASP.NET Forms have a nightmarish arrangement where some controls/properties auto-escape HTML and others don't. Crypto primitives are widely available but poorly explained. Multi-threading is a minefield. But even here, the industry can eliminate the widest number of security issues using secure-by-default design. In C# for instance, EF/Razor/TPL make it (1) easier to accomplish programmer intent while also (2) making it harder to break low-level invariants.

Think of VB macro viruses, that spread wildly in a managed language. Wordpress is another example of software written in a managed language with tons of exploits.

Office macros and PHP are some of the most hilariously bad designs in computing history. By necessity, any programming language worth its salt will let you make farcically bad decisions.

Notice (for example) his micro-agressions against people who understand garbage collection. The implication is you don't need to think about it, C# will take care of memory.......which if you take seriously, means you'll be leaking crap all over the place and someone like me will have to come clean it up for you.

As a Google developer, he can probably just throw clusters of auto-recycling web servers at the problem. Aside from opening avenues for DOS attacks, the consequences of this sort of problem (e.g., not knowing how your GC works) have more to do with performance/reliability than security (albeit the 3 are intimately linked).

Something we can probably both agrees on is that there's no substitute for knowing how things work. However, the reality is that most programmers don't care and even those who do have a limited mental budget for complexity. So there's also no substitute for being able to eliminate sources of complexity that are ancillary to the task at hand.

Comment: Happy Tablet User here. (Score 1) 272

by Qbertino (#48924499) Attached to: The iPad Is 5 Years Old This Week, But You Still Don't Need One

I bought an HTC Flyer about a year after it came out. I like my HTC phone, I liked the design of the tablet and its enclousure is still one of the best ever built. I mostly wanted to fiddle with it and programm a little for Android.

Turns out that I used it every day, for real work and leisure on the go. Calendar, docs, portable hotspot, reading, watching movies or short videolectures on the go, listening to music, audiobook, taking notes, playing games, etc. I'm since convinced of the feasibility of tablet computing.

I've recently decommisioned the HTC Flyer after more than 3 years of every-day full-scale use and bought myself a 10" Lenovo Yoga 2 Android with LTE module. Awesome device. Good enclosure, 9600milliamp battery, cost less than half of the inferiour iPad Air 2. It runs for 3+ days without charging and I plan to use it as my primary mobile computing device. Will carry my MacBook Air around less because of this I suspect.

As a result I'm using my 4,5 year old HTC Phone even less, which in turn means its battery runs even longer. On top of that, you can use the Yogas battery to charge your phone - that's a feature they (Ashton Kutcher) actually advertised on the Yogas first presentation.

There are pretty decent web IDEs and PHP environments for android out there.

My 2 cents.

Comment: Re:Open source code is open for everyone (Score 1) 208

by firewrought (#48918925) Attached to: Serious Network Function Vulnerability Found In Glibc

People who think that Java (or C#, or Python) language will fix their security problems write more security bugs than C programmers who work around the weaknesses of their language.

Apparently, your experienced C developer is still leaving holes for arbitrary execution, despite all of the tools (fuzzing/NX/ASLR) targeting this specific issue. Managed languages (like Java and C#) give you a "secure-by-default" memory and execution model that's a lot harder to accidentally mess up. The more "stuff" (languages, libraries, operating systems, etc.) that's secure-by-default, the less security holes we will have.

Comment: Re:You nerds need to get over yourselves (Score 1) 206

by jawtheshark (#48915003) Attached to: Why Coding Is Not the New Literacy

Jet fuel is to gasoline what gasoline is to diesel. It burns very quickly which as you can imagine makes it useful for an engine of this type.

Jet fuel is actually so much closer to diesel (and heating oil) than you imagine. Now, I know nothing about jet engines, but I did know that. Mainly because I tend to remember "interesting but useless facts". Link to Wikipedia

Give me a factory and a team of engineers from the 1860s

Typo? 1960, I buy, but in 1860? Not so sure... The birth of the car is generally put at 1886.... The Wright Brothers did they first powered flight in 1903.

Comment: Re:What about bandwidth OUT of the concentrator ?? (Score 1) 255

by satch89450 (#48905261) Attached to: Verizon, Cable Lobby Oppose Spec-Bump For Broadband Definition

Guarantee? What guarantee? Both DSL and cable internet service are provided on a "best effort" basis. If you want a SLA, you have to pay through the nose for it. Guaranteeing a SLA means the provider has to provision dedicated circuit capacity, instead of letting you complete for channel space on a first-come, first-serve basis.

With DSL, the uplink and downlink depends on the DSLAM-to-CO channel capacity, because DSL is implemented using ATM and virtual circuits in fiber rings. The differing up/down rates are a design decision, based on how many of the sub-carriers are assigned in each direction. Oversubscription is the carrier's choice.

True cable service is another story. The downlink is managed by the head-end, so the feed onto the cable can run at top rate. Yes, the more users who are on the subnet in your neighborhood, the slower things can go. The uplink, however, is a single channel shared by a number of sources, so the upstream channel acts like AloahNet back in the 60s: a fractional load can saturate the uplink because of contention. (ThickNet and ThinNet suffered from the same congestion problem...which is why most people use twisted-pair star networks, even in our homes.)

Comment: Re:The law is more specific. Quality voice, graphi (Score 1) 255

by satch89450 (#48905093) Attached to: Verizon, Cable Lobby Oppose Spec-Bump For Broadband Definition

POTS is 64 kilobits/s in the ideal case, 56 kilobits/s when the path is digital, about 48 kilobits/s when there are analog diplexing amps and such (which continue to go away, thank goodness). But not let's get caught up in nits...

When you talk about video, you are assuming a single stream of high-quality 1080p video. How many American homes have only one television? (Especially when there is such a glut of analog-only TVs available for a song with the switch to over-the-air digital.) (Or as large-format laptops continue to hit the previously-leased used computer stores.) You can easily have two streams in the poorest of homes, one for the alleged "grown-ups" and one for the kids.

When you start talking about VoIP, you need roughly 100 kilobits/s to handle a single voice conversation and side-channel control, considerably more if you have side-channel "whiteboard" traffic. That's per phone conversation. It adds up when your household has a number of people, and more so in SOHO.

And the cable companies in particular want to keep 1990 pricing as much as they can, because Internet is a cash cow for them when they get CCIEs to maintain the network gear -- an absolute necessity when the cables sell 100/100 fiber to larger businesses.

It's about profit and rate of return. And, unlike the other parts of their business, the rate of return on Internet is (for now) unregulated.

Nothing succeeds like the appearance of success. -- Christopher Lascl