Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:If you do go with C++ (Score 5, Interesting) 296

I think that really depends on your definition of "best". I've used Qt (and still use it sometimes) and initially I thought I liked it, but over time began disliking it a lot. For one, I've seen the signal/slot mechanism used to create really hard to understand code. I've seen memory allocated via new and then the pointer passed into emit only to be deleted on the other end of a signal/slot chain.

Posted says, "needs to manage memory usage and disk access at a very granular level and a desire to be cross-platform". Stdio/stdlib takes care of that. I don't see any mention of GUI, so if GUI is necessary, then I'd say, ya, just use Qt, because it probably is the best and it does come with a lot of other stuff, so you when in Rome...

Boost. What you'll get from boost is the filesystem stuff. It'll be similar in functionality as System.IO.FileInfo System.IO.Directory in .NET, but way more confusing to use. At least at first.

It's funny, the filesystem api was proposed over 9 years ago for c++.

http://www.open-std.org/jtc1/s...

Comment Re: Buggy whip makers said automobiles aren't... (Score 1) 451

I think the issue is more about whether people will trust a machine to make qualitative decisions on their behalf. I don't think I would. For starters, we've demonstrated time and again they were incapable of making reliable computer systems, and nevermind secure from tampering. Who can ensure me that the guidance system isn't going to core dump at high speed and slam on the brakes or worse? Secondly, how do test this system? There seems to be way too many scenarios where the best answer is subjective. You'd have to trust a computer system to evaluate risk where human life is at stake. I think the systems that Mercedes is building is much better. It seems to me they're heading towards a more augmented reality with feedback that can suggest a good choice, but allow me to make the final decision. If you're not familiar, they do the beak pedal tap and steering jar thing. That's at least a system I can trust. Then there's the whole liability thing. Does a self driving car come with the "this shit probably doesn't work" license like all other software? And lastly, the cost. What's the expected cost of a self driving car that's sure to be worthless on the used car market? I'd say in 10 years you'll still be buying vehicles that you command, and the more advanced stuff found in higher end cars will be had in lower cost vehicles.

Comment Re:What's wrong with Windows Server? (Score 1) 613

services.msc is the Microsoft Management Console snap-in for controlling the service control manager. It's really not the thing that's similar to systemd. I think the service control manager (SCM) itself is similar, but it also has an API for control and a couple command line interfaces (dos and powershell). I've actually worked on a project on FreeBSD (closed source) where the concept of an SCM type application always came up. In theory it could have provided a nice consistent interface to our "services" to do things like stop, start, query status, logging, etc. All the boiler plate stuff then looks the same from the outside, instead of being more adhoc. I guess with initd and all the shell scripts, you get a few logging utilities and then shell error codes. Other than that, it's pretty much open season.

Anyone who has written a service for windows knows a few things. First, you always need a way to run it as a normal windows console app or debugging it is a royal pain. Second, you better write it so that it shuts down properly or you'll be getting tons of questions about warnings and errors in the event log. Installing and un-installing can also be painful. I can't be certain how/why, but automating the installation, upgrade, and removal of the service was sometimes problematic if someone logged in and left the SCM control panel running.

Once you have all the kinks ironed out, it's really nice. Admins can start and stop things, install/run your service as different users both domain or local. They can also do things like restrict access to the network, etc. and it's all familiar to them. It does take some cooperation on the developer's part. It is possible to write a service that totally sucks. By sucks, I mean it's buggy and therefore doesn't play nicely with the SCM. Leaves cruft in the registry, and so on.

I had an opportunity to write code on windows (c++ and c#) for about 5-6 years after working exclusively on Linux, FreeBSD, IRIX, HP-UX, and Solaris for about 10 years. I really liked it a lot. I worked on win2k3 and xp, and then win2k8 and win7. I thought win2k8/win7 were both really nice. I was actually blown away about how good the MS IDE and debugger is. The shell still sort of sucks (powershell). I wish someone would write a 'native' shell for windows that was cool. I'd event settle for a dos prompt you can resize like an xterm.

Comment History is destined to repeat itself (Score 3, Interesting) 88

Is it or me does it seem more and more like SunOS, IRIX, HP-UX, VMS, Digital UNIX, and so on all over again? I sometimes wonder if this is the precursor to the second coming of windows. Microsoft is the only company that seems to be trying to unify all their "stuff" across various devices/platforms.

Comment Re:Python's problem (Score 1) 510

If you ever write a module extension that requires interaction with the GIL, you'll find yourself trolling through the interpreter source code trying to figure out when you should acquire/release the GIL. I can say, the experience was pretty fun and educational, but it just seems like concurrency within the interpreter itself was an afterthought. I would think that a relatively modern language like python would have 1st class support for threading in it's "official" runtime. (CPython). I agree with the original post, that the GIL is a huge shortcoming. As someone who's also written a lot of .NET wrappers around c++ libraries, I can tell you that in theory it's great, but in practice it's no where near as nice as having a fully "managed" implementation. For starters, portability now relies on that wrapper being available on your target platform. If you own the entire stack, that's fine, but there's still an additional maintenance cost. Also, a lot of people writing python code don't have the expertise to simply drop into c/c++, re-write a critical section of code, THEN write the language binding. No to mention when they're debugging, their code goes into this sort of "black whole" method call and comes back out... hopefully in a good state.

Don't sweat it -- it's only ones and zeros. -- P. Skelly

Working...