Plus, the general comment seems to be that the children are used to getting their own way, and have become used to immediate gratification of their wishes. Doesn't sound like it's got a whole lot to do with computers to me. It's certainly easier to leave pre-school kids in front of iPads that it would have been to leave them in front of the TV - they have more fun with the iPad than the TV. But it doesn't change the fact that this is simply bad parenting, and not a problem with technology per se.
Silverstripe is great, I've used it quite a bit and it does stand head & shoulders above the competition. But, possibly this is because it's written in PHP, it's dog-slow. Odd that the four comments above are all AC...
It's a problem because insurance cares about who's fault a crash is. If it's your fault, your insurance has to pay up - and they may even refuse to if they can prove negligence, in which case you have to pay up. Bad news all round. If it's the other parties fault, then same story but for them.
BUT - if it's some computer programmer in Silicon Valley's fault.. well, now we're in a whole other area. Do computer programmers need insurance now? It's a whole big liability clusterfuck, and I think it's entirely possible that it might prevent fully-automatic car driving in a general urban type environment from ever taking off, no matter how smart it gets.
Mind you, I thought that about fully-armed drones blowing people up too, and it looks like I was wrong there...
Can you help me out here? I would love to know what the crux of this little flamewar that's going on around here actually is. Near as I can tell:
1) init is pretty much just a bunch of shell scripts that are used to start & stop services. It, IMHO, qualifies as an unmitigated hack 2) systemd is... what? Something sensible that at least attempts to start & stop services in a standard way?
I mean, forgive me, but it seems that this is a vast improvement. Who wants a system that's basically a collection of scripts? That just seems so fragile and un-documentable.
And then, into this, comments such as yours are thrown:
No it hasn't. Process ID 1 should do very little. That has always been the premise of init systems. When you've got something that does the exact opposite then you've got a problem.
When I see a statement like that I think to myself - why. What is sacred about PID 1? Why should it do very little? How is this a premise of an init system? And would you be happier if PID1 launched systemd as, I don't know, PID2, and then did very little?
I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.
balancing the need to live in a peaceful society with the needs of the individuals to defend themselves
Well I'd opine that they rather fucked that balance up. Bit late now I suppose. And what kind of bent thinking sees a link between arming everyone and a peaceful society? It's the same logic that led to nuclear proliferation, and it makes no sense whatsoever.
That's not completely true. Crossbows are categorised as offensive weapons, and the police are going to take a reasonably dim view of you if you start carrying one around in public. From the nz police website:
"Bow and arrows should only be carried with a lawful, proper and sufficient purpose, for example you are taking your crossbow to archery practice or hunting."
Out of interest, BronsCon, how do you imagine those robberies would have gone if you'd had a gun of your own? I mean, would you have been able to point a gun back at them? And if so, what would have happened then?
I mean, it must be reasonably terrifying to be robbed at gunpoint, but I don't think putting an additional firearm into the situation is likely to improve matters.
Perhaps I'm wrong. It certainly seems that you Americans are altogether too fond of your guns.
Actually there's another issue here - Android's security model asks for all the apps permissions before you even get to install it. Whereas on iOS, permissions are asked for by the OS when the app attempts to access the protected APIs. iOS's model is far superior, since for one thing you get a feel for what the app wants the permissions for, and for another you can decline without un-installing the app.
So if a rogue game app were to suddenly ask for permission to access your contacts, you would be able to say 'no'. On Android, you get asked up front and (almost) everyone just says 'yes'. Doesn't work.
This is something I really completely and whole-heartedly agree with.
Related: At a conference earlier this year, a speaker made the point that since hardware speeds are not increasing at the rate they once were, it now makes more sense than ever (and it always made sense) to optimise your code.
Of course, it sounds like the type of optimisation you're talking about is basic algorithm choices and understanding complexity. Which is CompSci 101, but does rather appear to be on the wane. I guess that's a rant for another day.
That's completely true. But it remains the case that many of C++'s features can be used on those types of devices, and smaller ones too, and that includes templates. Though on programs of the size one tends to find on microcontrollers, there probably isn't much point. You certainly don't want to be dynamically allocating memory, but that's got nothing to do with C++ specifically anyway.
But you're certainly never going to running Java or anything else on those things. It's Assembly, C or C++, and that's it.
That means if you use the same template for different types then it will generate duplicated object code.
This isn't necessarily true. Well-written templates will defer to base implementations that avoid duplicated code. For instance, templated containers of pointer types should all wind up using the exact same implementation, with the type-safety only being there to keep the compiler happy. That same implementation may be usable for any trivially-copyable data of the same size.
Templates and macros are really not even close to the same thing.
You know it's funny, but I do take issue with the suggestion that shadertoy is written in javascript. It's not, it's written in whatever they call that shader language these days. The javascript just ships a bunch of shader code onto the graphics card, and then sits back and takes the credit. It's not even really HTML5 either, it's just a bunch of code running on your graphics card.
If you were to attempt to write an actual game in HTML5, with things like physics and opponent AI and all the stuff we've grown to love, then the story gets a little bit different.
Also, the Unreal Engine has been written in asm.js, which isn't HTML5 or javascript either. And is even further away from general acceptance and widespread support that HTML5 is.
Right. But on the other hand some people are demonstrably using a VPN to foil geolocation of their IPs. Since Hulu are required to ensure that those who view their videos are in the US, and since they can't ensure that this is the case for those behind a VPN, they have no choice but to block VPN users. Sucks, I agree, but there it is. If you were bound by those licence terms, what would your argument be for allowing known VPN IPs?
The whole business model of refusing people's money because of where they live is pretty spectacularly retarded, but some people clearly think it's a good idea, and some of those people run Hulu, and that's the end of that.
Well maybe. I'd argue the problem is the extent to which C allows you to shoot yourself in the foot, and therefore its suitability in security-critical environments like openSSL.
There are 7 billion people in the world. It doesn't take a large percentage of people to look at the code for there to be a large number
I'm sorry, but that's a really silly argument. You can't create a significant number of people doing a particular thing by doing the 'big number times small number = medium size number' trick. We hear that from marketing here at work, and it doesn't make any sense there either.
Choose safer programming languages that don't admit certain kinds of programmer error in the first place.
This. Have you seen the code that the heart bleed bug lay within? This love affair with bare-metal C, with hand-managing memory, etc etc - needs a really hard re-examination. Calling memcpy in a security-critical application? Seriously?
They may well think that - but the point is that they're wrong. Isn't it better to know that, than to continue to labor under the misapprehension that you're doing something useful?
I submit to you that even if there were no god, you would still know that it was wrong to hurt other people. I don't see why we need to imagine the existence of an external arbiter of morality to support that it's a bad idea to hurt each other. And that honesty is probably a good plan too - and that it's not generally conductive of a productive society to steal each other's shit.
It seems to me that these moral rules are pretty damn self-evident. I don't believe in a god of any kind, let alone a Christian one, and yet these moral laws seem obvious.
Be nice. Be nice to other people. Why do we need a supreme being to work this one out?
Slashdot Mirror
Good lord.
Yeah. You'll probably find something upwards of 90% of those people were innocent.
Plus, the general comment seems to be that the children are used to getting their own way, and have become used to immediate gratification of their wishes. Doesn't sound like it's got a whole lot to do with computers to me. It's certainly easier to leave pre-school kids in front of iPads that it would have been to leave them in front of the TV - they have more fun with the iPad than the TV. But it doesn't change the fact that this is simply bad parenting, and not a problem with technology per se.
In The Loop FTW. Now that's a TV series you can get behind.
Silverstripe is great, I've used it quite a bit and it does stand head & shoulders above the competition. But, possibly this is because it's written in PHP, it's dog-slow. Odd that the four comments above are all AC...
It's a problem because insurance cares about who's fault a crash is. If it's your fault, your insurance has to pay up - and they may even refuse to if they can prove negligence, in which case you have to pay up. Bad news all round. If it's the other parties fault, then same story but for them.
BUT - if it's some computer programmer in Silicon Valley's fault.. well, now we're in a whole other area. Do computer programmers need insurance now? It's a whole big liability clusterfuck, and I think it's entirely possible that it might prevent fully-automatic car driving in a general urban type environment from ever taking off, no matter how smart it gets.
Mind you, I thought that about fully-armed drones blowing people up too, and it looks like I was wrong there...
I care about getting sound AT ALL.....As for Windows, that stopped impacting my world almost two decades ago. Let. It. Burn.
Slight irony, since sound in Windows works fine... ;-)
Can you help me out here? I would love to know what the crux of this little flamewar that's going on around here actually is. Near as I can tell:
1) init is pretty much just a bunch of shell scripts that are used to start & stop services. It, IMHO, qualifies as an unmitigated hack
2) systemd is... what? Something sensible that at least attempts to start & stop services in a standard way?
I mean, forgive me, but it seems that this is a vast improvement. Who wants a system that's basically a collection of scripts? That just seems so fragile and un-documentable.
And then, into this, comments such as yours are thrown:
No it hasn't. Process ID 1 should do very little. That has always been the premise of init systems. When you've got something that does the exact opposite then you've got a problem.
When I see a statement like that I think to myself - why. What is sacred about PID 1? Why should it do very little? How is this a premise of an init system? And would you be happier if PID1 launched systemd as, I don't know, PID2, and then did very little?
I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.
Most other countries have figured that out actually.
balancing the need to live in a peaceful society with the needs of the individuals to defend themselves
Well I'd opine that they rather fucked that balance up. Bit late now I suppose. And what kind of bent thinking sees a link between arming everyone and a peaceful society? It's the same logic that led to nuclear proliferation, and it makes no sense whatsoever.
That's not completely true. Crossbows are categorised as offensive weapons, and the police are going to take a reasonably dim view of you if you start carrying one around in public. From the nz police website:
"Bow and arrows should only be carried with a lawful, proper and sufficient purpose, for example you are taking your crossbow to archery practice or hunting."
Out of interest, BronsCon, how do you imagine those robberies would have gone if you'd had a gun of your own? I mean, would you have been able to point a gun back at them? And if so, what would have happened then?
I mean, it must be reasonably terrifying to be robbed at gunpoint, but I don't think putting an additional firearm into the situation is likely to improve matters.
Perhaps I'm wrong. It certainly seems that you Americans are altogether too fond of your guns.
Actually there's another issue here - Android's security model asks for all the apps permissions before you even get to install it. Whereas on iOS, permissions are asked for by the OS when the app attempts to access the protected APIs. iOS's model is far superior, since for one thing you get a feel for what the app wants the permissions for, and for another you can decline without un-installing the app.
So if a rogue game app were to suddenly ask for permission to access your contacts, you would be able to say 'no'. On Android, you get asked up front and (almost) everyone just says 'yes'. Doesn't work.
This is something I really completely and whole-heartedly agree with.
Related: At a conference earlier this year, a speaker made the point that since hardware speeds are not increasing at the rate they once were, it now makes more sense than ever (and it always made sense) to optimise your code.
Of course, it sounds like the type of optimisation you're talking about is basic algorithm choices and understanding complexity. Which is CompSci 101, but does rather appear to be on the wane. I guess that's a rant for another day.
That's completely true. But it remains the case that many of C++'s features can be used on those types of devices, and smaller ones too, and that includes templates. Though on programs of the size one tends to find on microcontrollers, there probably isn't much point. You certainly don't want to be dynamically allocating memory, but that's got nothing to do with C++ specifically anyway.
But you're certainly never going to running Java or anything else on those things. It's Assembly, C or C++, and that's it.
STL is template based.
Yes it is.
That means if you use the same template for different types then it will generate duplicated object code.
This isn't necessarily true. Well-written templates will defer to base implementations that avoid duplicated code. For instance, templated containers of pointer types should all wind up using the exact same implementation, with the type-safety only being there to keep the compiler happy. That same implementation may be usable for any trivially-copyable data of the same size.
Templates and macros are really not even close to the same thing.
You know it's funny, but I do take issue with the suggestion that shadertoy is written in javascript. It's not, it's written in whatever they call that shader language these days. The javascript just ships a bunch of shader code onto the graphics card, and then sits back and takes the credit. It's not even really HTML5 either, it's just a bunch of code running on your graphics card.
If you were to attempt to write an actual game in HTML5, with things like physics and opponent AI and all the stuff we've grown to love, then the story gets a little bit different.
Also, the Unreal Engine has been written in asm.js, which isn't HTML5 or javascript either. And is even further away from general acceptance and widespread support that HTML5 is.
Jewellery should also be a work or art, or at a minimum superbly-crafted artisanal items, there's nothing "mere" about it.
Right. But on the other hand some people are demonstrably using a VPN to foil geolocation of their IPs. Since Hulu are required to ensure that those who view their videos are in the US, and since they can't ensure that this is the case for those behind a VPN, they have no choice but to block VPN users. Sucks, I agree, but there it is. If you were bound by those licence terms, what would your argument be for allowing known VPN IPs?
The whole business model of refusing people's money because of where they live is pretty spectacularly retarded, but some people clearly think it's a good idea, and some of those people run Hulu, and that's the end of that.
Well maybe. I'd argue the problem is the extent to which C allows you to shoot yourself in the foot, and therefore its suitability in security-critical environments like openSSL.
There are 7 billion people in the world. It doesn't take a large percentage of people to look at the code for there to be a large number
I'm sorry, but that's a really silly argument. You can't create a significant number of people doing a particular thing by doing the 'big number times small number = medium size number' trick. We hear that from marketing here at work, and it doesn't make any sense there either.
Choose safer programming languages that don't admit certain kinds of programmer error in the first place.
This. Have you seen the code that the heart bleed bug lay within? This love affair with bare-metal C, with hand-managing memory, etc etc - needs a really hard re-examination. Calling memcpy in a security-critical application? Seriously?
They may well think that - but the point is that they're wrong. Isn't it better to know that, than to continue to labor under the misapprehension that you're doing something useful?
But firmly believing that you absolutely do have the 'flu, will also cure your 'flu. So I'm not completely sure what your point is.
I submit to you that even if there were no god, you would still know that it was wrong to hurt other people. I don't see why we need to imagine the existence of an external arbiter of morality to support that it's a bad idea to hurt each other. And that honesty is probably a good plan too - and that it's not generally conductive of a productive society to steal each other's shit.
It seems to me that these moral rules are pretty damn self-evident. I don't believe in a god of any kind, let alone a Christian one, and yet these moral laws seem obvious.
Be nice. Be nice to other people. Why do we need a supreme being to work this one out?