You just create objects on the stack, let them handle their memory management internally and automatically clean up when they go out of scope.
You mean like this in Java?
public void myfunc() {
MyObject localObj = new MyObject(); }
When you exit the scope it's eligible for garbage collection. Unless you hang onto a reference it's not going to hang around. If you're leaking memory or resources in Java you're hanging on to them somewhere. If you were doing the same thing in C/C++ and you free the object while keeping the pointer around you're just creating a Heisenbug.
The fact that *EVERY* line of kernel code has to deal with those kind of issues is a byproduct of the monolithic kernel design, not what the code itself is doing.
I started off as a Unix kernel programmer in the late-80's, did a lot of stuff on supercomputers and went to Apple to work on Copland (micro-kernel). I/O subsystems can make good use of OO abstractions. OS X's IO subsystem is written in C++.
It's really time to look at microkernels again. There are some performance issues, but many of those will get smoothed out as they're hit and engineered around.
And btw, I notice that, with 99 comments in, nobody else has bothered to actually provide you with the links to the official Apple iOS developers or Android developers docs, api, tools, etc. I at least showed enough respect for you to expect you to benefit from them. Was I wrong? Only time will tell.
You know, if he can't use Google he's really bad off.
Back in 1990 if you were an experienced C developer and hadn't looked seriously at OO languages it was understandable. In 2014, if you haven't at least dabbled with C++, Java or C# I think it shows a definite unwillingness to learn. So that's why the OP is getting "condescending" answers like "just hire someone"
You don't know Apple, or iOS developers. Dominant over ObjC within two years (and by the end of next year that prediction will probably seem ridiculously conservative).
Oh really? Drink some more koolaid. Remember how long it took to lay Carbon to rest. And the Cocoa APIs are still incomplete in many areas. Then take a look back at all the new programming languages and frameworks Apple has introduced over the years and then shot in the head. Dylan? OpenDoc?
I'd say it's 50/50 whether or not Swift will get enough traction to continue on.
If you've spent this long avoiding modern languages why start now? If you're not interested in object oriented design you're just going to spend your whole time cussing at the frameworks. Just hire a contractor.
Untrue. I've had the X server hang up and I've logged in via the network and killed it and restarted it. I can't restart systemd without restarting the whole system. Furthermore, I don't run the X server on our mission critical machines.
The point being that Apple didn't adopt Objective-C just to be weird. Next used Objective-C to build NextStep and there's certain things in Objective-C that made NextStep moderately cool.
I actually worked at Apple, on the operating systems team, around that time. Apple was in no position to be arrogant in 1997 and wasn't actively looking for ways to be incompatible. Today, that's a very different story.
Sorry, old Unix guy here. My first reaction was "What the F is pkexec and why is it running setuid?"
Yet another way to execute arbitrary privileged executables is yet another potential security hole. This dumb thing is apparently part of the "Free Desktop" but it's depended on by all kinds of stuff including the fricking RedHat power management. What's wrong with plain old sudo?
The question is, who is "you" and when does that checking happen? I don't do a lot of work in Python, Ruby, etc. and all of the programmers that I know who do are fairly young and working on fairly small projects so they don't have a good answer for refactoring.
If I change the arguments to a method in a statically type language any place where I forgot to change the call to that method will be exposed at compile time. As far as I've been able to learn so far, in most dynamically typed languages that check won't happen until runtime. The pat answer to that is "you should have unit tests that cover everything" - but getting complete code coverage is hard and for large projects, the test suite takes a non-trivial amount of time to run - usually much, much longer than compile time. So, you wind up with bugs at runtime. Or is there a better solution?
Technically, I see how it works but why would a merchant accept this thing? It doesn't look like a credit card and it's missing all of the anti-fraud elements built into the physical cards. According to their FAQ, Coin is trying to substitute an image on your smart phone plus their gadget for your physical card but I don't see that any of the actual credit card issuers are actually endorsing this. As a merchant you might be in violation of your merchant agreement by accepting this thing.
The Blu-ray disc needs to be mounted before it can be accessed. The ratio of robotic mechanisms to discs becomes important. If you need to mount ten discs, it takes ten times as long (if they're all using the same arm) whereas you could spin up ten hard drives simultaneously.
I've worked with large scale robotics since the late 80's. The performance of the arms has not increased significantly since then. When you're dealing with scientific datasets or backups it's not as much of a problem. In random access storage, though, it starts to be an issue.
Also, as they proliferate, they're going to have to deal with vandalism. A gas station is a neatly concentrated resource with oversight, security and even they still get vandalized.
Don't whiz on the electric fence!
Things like pricing can always be messed with. I think the maintenance issue, as the network grows, will become challenging. We'll see, though.
And in 1900 the same arguments applied against gasoline cars and you could get food for your horse, have a stable to keep it in, find a blacksmith to put new shoes on your horse, etc. just about anywhere.
The technology for EVs is still pretty early and just starting to improve. Give it another 10 years and it will probably address most of your concerns.
It might keep a few out but there are people who get their jollies out of trolling and the outrage that they create and might be willing to pay a few bucks for their hobby. It's been going on at least since Usenet (mid 80's).
I do enjoy small scale discussion on Facebook. I usually limit people who can post on my comments to friends of friends and that keeps the discussions more civil and usually more relevant. Perhaps the real problem is just that the number of people who can post a comment on many discussions is just too large. There is the risk of living in an echo chamber, though. Maybe a discussion site that creates groups with a representative sample of views, etc.
They get an unlimited bonus structure so that there's no limit to how much they will sell. Sales people are greedy bastards and they will follow the money trail management creates, regardless of whether it is good or bad for the company. Structuring the sales compensation is very important - I've seen many instances where the salespeople are doing things that are not good for the company but maximize their payoffs.
Why do sales people wind up in charge? Because they sell everyone else on how wonderful they are. If you don't have a management team with some real knowledge of the business you will wind up with self-promoters running everything.
Slashdot Mirror
Yeah, it only took him 20 years to figure out that he needed source code management.
You just create objects on the stack, let them handle their memory management internally and automatically clean up when they go out of scope.
You mean like this in Java?
public void myfunc()
{
MyObject localObj = new MyObject();
}
When you exit the scope it's eligible for garbage collection. Unless you hang onto a reference it's not going to hang around. If you're leaking memory or resources in Java you're hanging on to them somewhere. If you were doing the same thing in C/C++ and you free the object while keeping the pointer around you're just creating a Heisenbug.
The fact that *EVERY* line of kernel code has to deal with those kind of issues is a byproduct of the monolithic kernel design, not what the code itself is doing.
I started off as a Unix kernel programmer in the late-80's, did a lot of stuff on supercomputers and went to Apple to work on Copland (micro-kernel). I/O subsystems can make good use of OO abstractions. OS X's IO subsystem is written in C++.
It's really time to look at microkernels again. There are some performance issues, but many of those will get smoothed out as they're hit and engineered around.
And btw, I notice that, with 99 comments in, nobody else has bothered to actually provide you with the links to the official Apple iOS developers or Android developers docs, api, tools, etc. I at least showed enough respect for you to expect you to benefit from them. Was I wrong? Only time will tell.
You know, if he can't use Google he's really bad off.
Back in 1990 if you were an experienced C developer and hadn't looked seriously at OO languages it was understandable. In 2014, if you haven't at least dabbled with C++, Java or C# I think it shows a definite unwillingness to learn. So that's why the OP is getting "condescending" answers like "just hire someone"
HA HA HA HA HA HA HA
You don't know Apple, or iOS developers. Dominant over ObjC within two years (and by the end of next year that prediction will probably seem ridiculously conservative).
Oh really? Drink some more koolaid. Remember how long it took to lay Carbon to rest. And the Cocoa APIs are still incomplete in many areas. Then take a look back at all the new programming languages and frameworks Apple has introduced over the years and then shot in the head. Dylan? OpenDoc?
I'd say it's 50/50 whether or not Swift will get enough traction to continue on.
If you've spent this long avoiding modern languages why start now? If you're not interested in object oriented design you're just going to spend your whole time cussing at the frameworks. Just hire a contractor.
That's my question. I've wound up with it installed plenty of times because it's the default on too many distributions but use?
At least with terminals you could arrange them how you like. Ah, the joys of 3 VT100s on your desk.
Untrue. I've had the X server hang up and I've logged in via the network and killed it and restarted it. I can't restart systemd without restarting the whole system. Furthermore, I don't run the X server on our mission critical machines.
The point being that Apple didn't adopt Objective-C just to be weird. Next used Objective-C to build NextStep and there's certain things in Objective-C that made NextStep moderately cool.
I actually worked at Apple, on the operating systems team, around that time. Apple was in no position to be arrogant in 1997 and wasn't actively looking for ways to be incompatible. Today, that's a very different story.
Those would be called "antivirals"
Sorry, old Unix guy here. My first reaction was "What the F is pkexec and why is it running setuid?"
Yet another way to execute arbitrary privileged executables is yet another potential security hole. This dumb thing is apparently part of the "Free Desktop" but it's depended on by all kinds of stuff including the fricking RedHat power management. What's wrong with plain old sudo?
No, that's not right. You have to pull the finger. I'll show you. Pull my finger.
The question is, who is "you" and when does that checking happen? I don't do a lot of work in Python, Ruby, etc. and all of the programmers that I know who do are fairly young and working on fairly small projects so they don't have a good answer for refactoring.
If I change the arguments to a method in a statically type language any place where I forgot to change the call to that method will be exposed at compile time. As far as I've been able to learn so far, in most dynamically typed languages that check won't happen until runtime. The pat answer to that is "you should have unit tests that cover everything" - but getting complete code coverage is hard and for large projects, the test suite takes a non-trivial amount of time to run - usually much, much longer than compile time. So, you wind up with bugs at runtime. Or is there a better solution?
OK, that's bullshit.
Technically, I see how it works but why would a merchant accept this thing? It doesn't look like a credit card and it's missing all of the anti-fraud elements built into the physical cards. According to their FAQ, Coin is trying to substitute an image on your smart phone plus their gadget for your physical card but I don't see that any of the actual credit card issuers are actually endorsing this. As a merchant you might be in violation of your merchant agreement by accepting this thing.
The Blu-ray disc needs to be mounted before it can be accessed. The ratio of robotic mechanisms to discs becomes important. If you need to mount ten discs, it takes ten times as long (if they're all using the same arm) whereas you could spin up ten hard drives simultaneously.
I've worked with large scale robotics since the late 80's. The performance of the arms has not increased significantly since then. When you're dealing with scientific datasets or backups it's not as much of a problem. In random access storage, though, it starts to be an issue.
Also, as they proliferate, they're going to have to deal with vandalism. A gas station is a neatly concentrated resource with oversight, security and even they still get vandalized.
Don't whiz on the electric fence!
Things like pricing can always be messed with. I think the maintenance issue, as the network grows, will become challenging. We'll see, though.
And in 1900 the same arguments applied against gasoline cars and you could get food for your horse, have a stable to keep it in, find a blacksmith to put new shoes on your horse, etc. just about anywhere.
The technology for EVs is still pretty early and just starting to improve. Give it another 10 years and it will probably address most of your concerns.
Superchargers aren't "free" - you pay $2K for access and then it's "free" for the lifetime of the car. This guy thinks that Tesla actually makes money on the program
Some people like nested virtual machines, some people like candy colored buttons. What else are you going to do with all those resources? :-)
Despite the name, DOS was not an operating system
It's kind of silly but no worse than network file systems. And, containers don't have that virtualization overhead.
It might keep a few out but there are people who get their jollies out of trolling and the outrage that they create and might be willing to pay a few bucks for their hobby. It's been going on at least since Usenet (mid 80's).
I do enjoy small scale discussion on Facebook. I usually limit people who can post on my comments to friends of friends and that keeps the discussions more civil and usually more relevant. Perhaps the real problem is just that the number of people who can post a comment on many discussions is just too large. There is the risk of living in an echo chamber, though. Maybe a discussion site that creates groups with a representative sample of views, etc.
They get an unlimited bonus structure so that there's no limit to how much they will sell. Sales people are greedy bastards and they will follow the money trail management creates, regardless of whether it is good or bad for the company. Structuring the sales compensation is very important - I've seen many instances where the salespeople are doing things that are not good for the company but maximize their payoffs.
Why do sales people wind up in charge? Because they sell everyone else on how wonderful they are. If you don't have a management team with some real knowledge of the business you will wind up with self-promoters running everything.