Follow Slashdot stories on Twitter


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

Comment Re:Here come the science deniers (Score 1) 560

No denying here. I would also like to understand what long term effects alcohol has on the brain as well in comparison.

If there are equally bad mental health problems associated with use of both substances, then we can come to a conclusion about legalization or not of any mind altering drug - including those things that are currently legal most places. Once we understand the relative impacts - we can make better decisions rather than coming to a conclusion about a single substance in isolation.

That is science.

Comment Re:The answer is no, this is pointless (Score 1) 230

There are several problems that seem insurmountable:

1. While you could block the internet from directly interacting with these devices - by definition something would need to interact with the widget - either directly or as a proxy - unless you are okay without remote access.

2. If you have a machine on your network that interacts with the device, and also interacts with the internet (say for web browsing - http protocol) - then a bug in your machine could be a conduit for further access to the IoT device.

The only way to be absolutely sure a device is secure is to not have it connected to the network -

Comment Re:It's pointless (Score 1) 260

It is a code of conduct violation to remove (print) proprietary and sensitive business documents from the systems they reside on. Editing tools are sufficient to read and mark up - as well as version control these documents. Needing paper is a crutch for people who have too much time on their hands (you have to print the document, mark it up, then type in your edits, and load/save the new version --- too many steps take too much time).

I deal with hundreds to thousands of business documents over the course of many years; there is barely enough time to read them before feedback is needed.

That being said - this does not take into account legal documents that have requirements to keep paper copies in file cabinets under lock and key -- but that is for the legal assistants and lawyers to deal with --- not the vast majority of people in business.

Comment Re:Hardest problem (Score 1) 497

Not all 'computer science' cirriculae is equal either - particularly in recent years.

This is why I've long advocated never being 'just a programmer', or any other pigeonholed job for that matter. Define your work on your own terms as much as possible. When I first started working as a system admin / technical support specialist on the night shift (yeah - they had me doing two jobs at once) -- I took the time to automate a number of things, including the then current paper ticket system they kept in a binder and passed from shift to shift, as well as many of the systems checks and maintenance activities. As I moved to new jobs in the company, I continued to do this - providing value add, as well as easing my own workload burden along the way. I wouldn't say I'm indespensible - but I've managed to survive through 20 years of reorganizations, layoffs, and offshoring that severely impacted my 'just a programmer' peers.

Comment Re:fraud (Score 1) 497

There are many excellent points here - and as a programmer since I was a teenager and also in my 50s now - I have also thought about this problem a long time.

A good visual analogy to a computer system is Russian nesting dolls. Each doll can be equated to an underlying system and associated languages. At the deepest innermost layer you have microcode - running on an extremely simple state machine that has code written for it to emulate a Von Neuman central processing unit (CPU). Next comes binary numbers that can be inserted into registers and memory using the CPU. Up from that is assembly language - which is another extremely simple langauge used to communicate with the CPU in native binary. Above that are a plethora of compiler based languages - that essentially convert their human understandable grammars into native binary (or intermediary assembly language - and then to binary...details). At the same level there are also interpreters - which are interactive languages that can be programmed 'on the fly' one line at a time; each line is acted upon immediately when you enter it - and were used effectively for teaching students... Basic being one such language. They could also be used for high performance computing - LISP being an example. It's important to point out at this point - all languages don't have to be loaded on a given system - these are just the possibilities.

Now things get really interesting: virtual machines. A virtual machine is a simulated CPU that has its own simplified instruction set that an applicable language can compile against. The nice thing about a virtual machine, is it can be deployed across many different hardware architectures without the need to recompile your programs. Examples are Java's JVM, Python's virtual machine, and Javascript V8 virtual machine.

Finally you have application frameworks - collections of libraries and other functions that allow you to quickly build applications with less work - because most of the heavy lifting is already done for you. In this category I would also lump code generators - like the Unified Modelling Language (UML) - that has tools which takes a program defined using the UML language - and generates code in a specified programming language.

There are far more complexities to this than I've listed here. However, you can think of this in almost archaeological terms - each layer over time making it easier or faster for someone to build applications using a computer. Spreadsheet programs are a good example of building systems that allow an end user to leverage the power of the computer to handle complex calculations with little need for the user to understand programming at all.

That being said, I agree there are a lot of extraneous languages, frameworks, and development environments out there that makes it more likely that people will create buggy code. The farther away from the CPU - in terms of abstraction - the less you will know about what your application is really doing 'under the hood'. As a result, I do suggest a clear bias towards simplification in the selection of languages used to build the underlying systems for the use of people to solve problems, coupled with perhaps certification programs to make sure what is being built is being built good.

Comment Re:Snowden also did something illegal (Score 1) 361

The real conspiracy here is why we spend so much time fighting over things that are fringe issues. We know we can't get compromise on these things - so why do we focus on them - when it would be more beneficial to work together on things we can find common ground?

I believe most people in the country are willing to work together to solve common problems. We have proved that over and over again throughout our history. Sadly, this comes only when the country is existentially threatened. Hopefully that won't be too late the next time it happens.

Comment Re:Production bugs do not cost what they once did (Score 1) 167

Zero days cost more than all the floppy disks and CDs combined. Back in the day - most things were not networked. Today that's all there is*. Those flaws hurt the customer and the company, and depending on what we are talking about (e.g. network connected cars and industrial control systems) may cause loss of life and property.

The problem space isn't as cut and dried as you would make it out to be.

( * Note: I know that isn't all there is...but I would argue the amount of stand alone non-networked apps out there today is statistically insignificant. )

Comment Different Concepts Are Needed (Score 1) 167

The prime directive of anyone associated with building software for end users must be to create bug free, secure systems that are effortless for people to use.

This needs to flow throughout an organization - whether you are the architect, designer, marketer, developer, tester, accountant, whatever. Everyone must be on the same page when it comes to this goal. Everyone needs to really understand what that entails in practice.

I've been both on the building, and receiving end of things when this goes wrong - and it goes wrong too often than is necessary, primarily because an organization does not have that unifying goal. From a user's perspective it sucks because you end up with a confusing mish-mash of tools with no unifying concept behind the interfaces, and which fail to integrate data effectively to avoid redundancy. 'Painful' is a good adjective that describes using such systems. From the developer's point of view you end up unable to do your best work. Finance or management doesn't provide the right resources, time, or unifying definitions for the solutions in the company's stable - everything seems to be a one-off that you end up throwing over the wall until the next project comes along. Responsibility and ownership is minimal at best - leading to long nights debugging production code, and too many times devolves into finger pointing and recriminations.

Given the current state of affairs I think it is time for people to find new concepts of how software and systems development really should work for all of us.

One thing that occurs to me is we should stop rewarding companies / projects (in the case of open source) for producing poor quality systems and software. If you want to build crufty systems for yourself, that's one thing. Don't foist that off on the public. A way to make it easy for end users to identify such systems could be a certification mechanism - an independent body that could look at various criteria to rate software and systems on an scale (e.g. unrated, low quality, medium quality, high quality, etc). The criteria used could be things that matter - such as bug history, security bug history, availability of code for independent review, complexity vs. simplicity of code reviewed, ease of use, ease of integration with other systems and data, etc.

Similarly, I think development tools, and organizations and companies that develop tools and systems should similarly be rated to allow potential consumers and users of their work to make more informed decisions.

Comment Re:Technically not illegal (Score 1) 361

The Supreme Court has upheld the freedom of speech in a large number of cases including:

Snyder v. Phelps (2011) (Westborough Baptist Church), National Socialist Party v. Skokie (1977) (NAZIs) Brandenburg v. Ohio (1969) (KKK), and Terminiello v. Chicago (1949) (Gave speech in Chicago that caused protesters to riot).

Not sure what 'hate speech' laws you are talking about.

...Unless you are talking about foreign countries - in which case they can similarly attempt to extradite etc. Not quite sure where you are going with this.

Slashdot Top Deals

Save yourself! Reboot in 5 seconds!