Become a fan of Slashdot on Facebook


Forgot your password?

Comment No NoScript = no Firefox for me (Score 1) 465

The main reason that I stick with Firefox is the NoScript extension. If that stops being available for Firefox, I will stop using Firefox.

Javascript is the vector for 99% of the attacks on the Internet. There is no substitute for an extension that shows you what scripts a page wants to run and allows you to selective enable those sources - either temporarily or permanently.

Comment Good luck changing culture (Score 1) 181

The problem indeed, is half cultural; as I wrote in my book High Assurance Design,

  1. The average programmer is woefully untrained in basic principles related to reliability and security.
  2. The tools available to programmers are woefully inadequate to expect that the average programmer can produce reliable and secure applications.
  3. Organizations that procure applications are woefully unaware of this state of affairs, and take far too much for granted with regard to security and reliability.

At this point, I think that the only way to change the culture on this issue is to make software writers partly or fully liable for the security breaches that result from vulnerabilities in the code. Nothing else will cause security to rise to the top of the priority list.

On the other hand, the problem is partly technical: the procedural Von Neuman programming paradigm leads to terrible design. Alternatives such as data flow, event-driven, and functional design are much more robust; but one needs to use languages that support those, and the popular languages are primarily procedural, so again, it comes down to culture.

Comment #1 in POPULARITY (Score 3, Insightful) 372

"Popular" != "Best"

Also, one should choose the right language for the task. The right language for a small office task is not usually the right language for a scalable microservice. E.g., Google discovered long ago that if an app written in Ruby or Python requires 100 servers to meet demand, but the same app written in C++ or Go requires only ten servers, then there is a substantial cost difference. (Although Go is quite terrible for maintainability - do a Google search for "Go gotchas".)

Ignore popularity. Make your own choices.

Comment Not surprised (Score 2) 253

Ruby is fantastic for writing a-lot of code quickly. But it has terrible performance, and is has terrible maintainability characteristics (I recall doing global file system searches to find the file that defines something that my code requires, which is brought in by another require, and then another).

Performance sometimes matters. If one's app requires 20 VMs in Ruby, but only 2 VMs in Go or C++, then the cost difference can be substantial.

Also, Ruby - while 20 years old - is surprisingly immature. E.g., a few years back, I wrote a multi-threaded program in Ruby. It didn't work. After days of scratching my head, I discovered that while Ruby used native threads, it had a global interpreter lock, forcing the native threads to take turns. Maybe they have fixed this by now. My program needed true concurrency, so I had to re-write it using processes. Gosh - Java got threads working after the first two years.

Firms that really know how to maintain large codebases have also discovered that type-safe languages are very effective for maintainability. Check out this post: https://medium.freecodecamp.or... . I myself have experienced this: I once translated a fairly good sized codebase from Ruby to Java, and in the process discovered a large number of potential bugs - thanks to Java's type safety. I have found that when I refactor Java code, I introduce zero new bugs, but when changing Ruby code, the only thing that prevents new bugs is a large suite of unit tests. Thus, writing in Ruby _requires_ that one write comprehensive unit tests. I personally don't use TDD - I use ATDD, so my focus is on acceptance tests, not unit tests. Ruby _forces_ me to write unit tests. I don't want to be forced to work a certain way.

I am not bashing Ruby - I think it is great for some things - but people (like those at Google) have come to understand its shortcomings.

Comment Re:Science is not about facts (Score 1) 279

I know what theory means. You are the one wasting your own time, fella, by responding to something that you are clearly not interested in: if you are not interested in what I have to say, then perhaps you should keep your empty lowbrow thoughts to yourself and stop wasting your own time. It also amazes me how rude some people - like you - are in this forum. I really doubt that you would address me this way in person. Hidden behind a browser you are fearless. In person, I doubt you would be so fearless - and I'd probably punch your teeth in. Moron.

Comment Re:Science is not about facts (Score 1) 279

What a nasty reply. I will respond anyway - perhaps others are interested in actually exchange ideas instead of insults.

Observations are facts - to the observer (not necessarily to others). However, theories are not facts. Gravity is a good example, because while we thought we understood gravity, it turns out that we don't - there are some predictions that general relativity makes are in conflict with quantum mechanics. So the theory of gravity is not a "fact" - it is just a theory.

That does not mean that theories don't have predictive value: of course they do; but there is always a margin of uncertainty - sometimes very tiny. No theory is absolute - no theory is a fact.

Comment Not so sure (Score 1) 268

The thing I like most about today's languages is type safety - because type safety enables me to refactor without worry - and without having to write lots of tests as a safety net - but not all "modern" languages have type safety. Also, about two years back, I had to write a program to parse the output of tcpdump. I thought about writing in ruby, but that would mean that I would have to install ruby on the vm where the code would be running, so I wrote it in C. It took me about an hour to code, and was about 150 lines. It worked _the_ _first_ _time_. The first time. And I had not written a C program in 15 years. So I am not so sure that "modern" languages are that much better.

Comment Re:It's A Start (Score 5, Insightful) 619

I don't think that age is relevant. I am 61, and I am completely current in my field (containers, Kubernetes). A few years back I worked at a small company populated with "DevOps" folks - all younger than me - and I ended up leaving because they were not able to mentally shift from VMs to containers. Age is not the issue. Also, while most of "middle America" is not going to turn into programmers, some of the young people in middle America who are just starting out might pick an IT career if they think there is opportunity in it - but they won't if all the jobs are taken by H1B people.

Comment The flaw in the idea (Score 1) 723

A universal basic income would have to be at a subsistence level - so it is only relevant for young college students (no house, no kids) and those who are destitute. E.g., if an IT worker were out of work, a basic income would likely be too low to even make a dent in their expenses. If the basic income were at a higher (non-subsistence) level, then most people, if they actually did not have to work to live decently, would pursue activities that they enjoy but that have little economic value. It is an idyllic vision, but unfortunately is not practical - not unless we implement communist-like control of all infrastructure and manufacturing - but we saw how well that worked.

Comment Re:Why is that useful? (Score 1) 189

I don't claim to know the best solution for this. I was merely sharing my own experiences. Have you used the Outlook Web client? It is pretty effective, IME. I have used it quite a bit, but I am sure there are shortcomings that I have not come across. I also wonder (I don't know) if MS apps like Word can now be deployed in a private cloud. If so, perhaps that could be a solution.

Comment Re:Why is that useful? (Score 1) 189

I think you are jumping to conclusions about me. This is not about me.

You are right that it is not just about process. Process is part of it. The largest issue, IME, is knowledge: do people know about VMs? Containers? ATDD? DevOps? etc. - at all levels, from the developers through the various managers who set the rules (and therefore can change the rules).

One thing that I have found is that if you give developers Windows machines, they learn that - they don't learn about Linux. That's fine if the org deploys on Windows, but if it deploys on Linux, it is nice if the devs know about Linux; and if you want them to know about Linux, the best way to achieve that is to have them live in Linux most of the time.

There are always exceptions: people who will learn all of the envs. That's why I don't believe in forcing people to use one env over another. Most of my work is in large organizations where one has to think about the range of skills and personalities.

PS - Don't assume that because I am an Agile transformation coach that I am not technical - I am (I code).

Slashdot Top Deals

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page