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

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re: Linux. (Score 1) 400

Wow, way to over-think things.

What I am saying is my experience with a Mac was wholly under-whelming. You may have been able to make things work. Bravo for you. My experience with a Mac has been trying to get a square peg to go into a round hole.

Photoshop, some involves Maya and or Lightwave. Some involves PowerPoint, and some involves Excel

Everyone can do this. It's not hard. Hell my *phone* can do it. Altering text files to configure two disparate systems to speak with each other? Fantastic.

But what can your Mac talk to as far as equipment is concerned? Industrial automation? Sensor to shooter systems? IC2? PWM? High traffic network servers ?

No.

Comment Re: Linux. (Score 0) 400

imho, Macs are great at giving people the impression they are getting shit done, when in reality a lot of times it's really only consumer level word-processing that's going on.

Hell you can barely game on a Mac. I gave one a real try when I was a DOD contractor. There wasn't squat I could do with it but use it for the web, email, and making documents.

When you want to connect external peripherals to interact with the rest of the world you aren't going to see Macs. You're going to see PC's running Linux. There are no professional Mac embedded systems that are mature, robust or widely known.

Comment Re:Third choice (Score 1) 275

Easy enough to say but last time I checked if you want to do anything with the current VR headset boom, you're pretty much going to have to use Windows. Steam's OpenVR initiative makes it sound like you don't, but a few months ago when I checked their Linux examples wouldn't even build.

Comment Re:Meh (Score 1) 179

Is there every any particular need to limit them, though? A couple decades ago it was uncommon to have more than one sound device on a machine. Now it's unusual not to have two or three. Designs and requirements change over time, and having to factor out singleton behavior that was never really necessary in the first place is kind of a pain in the ass. You could easily just create those things with thing factories when the program starts up, and pass them around to objects that need them. No artificial limits, and you don't have to factor out singleton behavior when you decide you want two things where you used to only have one.

I've found that design review boards are becoming increasingly hostile toward singletons, too. There was a narrow window where they'd at least consider one, back when people started talking about design patterns. These days it's next to impossible to get one approved, even if there's pretty good justification for it. You can always design around the need for a singleton, and usually the system design will be better without them.

Comment Meh (Score 5, Interesting) 179

I've yet to see a computer science professor with particularly excellent code, either. I run across assignments and example code from courses on a regular basis that fall into the "Never, ever do that" category of programming. Case in point, a relative of mine recently had some questions about a CS programming assignment. Part of the assignment description talked about design patterns and predictably went straight for the Singleton as an example. I'm pretty sure that's the only pattern that about 90% of programmers ever actually learn when reading about design patterns and it's so abused in the industry right now that you can basically never get one past a design review board.

Anywhoo, back in the '90's I worked for a company that was getting a B2 Certification for its operating system. My job basically consisted of reading the entire AT&T C standard library code, finding potential security flaws, writing tests for those flaws and then writing a report with the tests which would be delivered to the NSA. I found the remote buffer overflow in the AT&T telnet daemon a couple years before the same overflow was discovered in the Linux telnet daemon. So the NSA basically outsourced the hard work of finding all those exploits to the companies that were trying to get security certifications. It took three or four guys just a few months to go through all the stuff we had to look at. I'm sure we missed a bit, but I was much more confident in the security of their OS at the end of all that. Too bad they eventually went out of business, were acquired by IBM and their products were killed. You know, progress!

Slashdot Top Deals

"We don't care. We don't have to. We're the Phone Company."

Working...