it sounds like it turns your pc into a console. And this is a bad thing? There is a reason that
console games are getting popular (outselling the pc games, IIRC). Not having to futz around with drivers, not having to check system requirements, not having to... well, do lots of things...
I rather like the idea of booting my PC just to play games
Of course *you* wouldn't go for this - it isn't aimed at you, it's aimed at consoler gamers
If he asked for your brothers name, he should have used wikipedia's page on Hindu Gods, then tape the conversation. Won't work - it is fairly common amongst indians to name their children after their gods, hence names like Krishna, Vishnu, etc
Actually, those are specifically spelled out as part of IT's job where I work. And people do indeed get fired for violating policies along those lines.
Which justifies the assumption that IT is on a power trip.
Face it, if they're power grabbing for priviledges they do not need, it's time to outsource.
You may WISH it was your bosses job, but frequently its ICT staff who get the blame for you watching porn.
Hell no - Every organisation I've worked at in the
last twelve years had a *policy*. Not once, in any of my twelve years working both ICT and user, has ICT *ever* been blamed for a user slacking off at work. I'd bet dollars to donuts that your dept. has a policy spelling out that ICT is not liable for anything that the user does (like porn).
"Why was he able to do that, cant you block that stuff?" We had a network manager almost fired because she unblocked someone because they claimed they needed it for a project and in turn was watching KIDDY PORN at work.
Irrelevant if there was a company policy in place. I find it hard to believe that you work at a place that has written policy that blames ICT for the user being able to use the service for illegal activities. No one is getting fired other than the user themselves.
His boss didnt get the axe, SHE almost did. So you can make the claim all you want its not our jobs, but your bosses say otherwise.
Actually, my claim is that it is written down that ICT is not liable - if you work at a place that does not even have a phones/ICT policy, leave. All such policies I've seen make ICT not responsible for anything.
And you should see what middle management approves sometimes. Maybe if we could trust them to approve legitimate packages then sure, but Half Life 2? (true story)
Doesn't matter how true it is - if the users supervisor approved it it's none of your damn business. Your job starts and ends with making sure that the signature is authentic. You are nowhere near knowledgeable nor skilled enough to determine what is legitimate for a user.
Once again I must stress - if a user is slacking off, then it's not your job to police that; just inform their manager. Their manager would have to police the users productivity.
Sorry to say in the real world when it comes to computer work, we are as much your boss as your boss is.
Nope - you are sort of proving the theory that ICT prefers to power-grab rather than facilitate. Really, you are in no place to police users - simply tell their managers.
If you dont like it, go back to using paper.
And it is this statement that confirms that all you (assuming you are in ICT services at your company) want is more power. Given your relatively clueless attitude about my needs, paper would be preferable. However, the current trend is to simply give less power to ICT to police. If ICT doesn't like what software some user is running, they can simply complain - cutting someone off should be a fireable offence for ICT staff.
But the fact is in the nearly 10 years I have been doing this, the user cant be trusted to push the power button, forget about actually making important decisions that could potentially effect other machines.
Likewise, users don't trust ICT services to find a clue with both hands and a map.
I don't know if you've used an operating system written in the last 10 years, but exactly the same is true with malloc(). Operating systems these days tend to use lazy allocation. Malloc will return a valid pointer, but when you use it then you will get a segmentation fault.
Yes, that behaviour can be tuned though - FreeBSD
allows tuning knobs for it, IIRC. However the C standard makes it clear that malloc returns NULL on failure - IOW the contract you've got with the hosted C implementation is "as long as the standard is adhered to, the code will work". The developer codes according to the standard and trusts that the implementation is compliant. You are advocating second-guessing the implementation? What if the user of the program turned off lazy allocation?
FWIW, I've not come across a free-standing implementation that uses a lazy allocation scheme.
I have had people at work constantly rag on my department for simular concerns and what does it always turn out to be. We unblock them and instantly the sites like parezhilton and myspace pop on, or the aim client is loaded up, or you find out their request for a certain software program turns out to be a package they have no business running and are scamming their boss into buying for them so they can take it home.
Who determines if the user has any business running a certain piece of software? If their boss approves it, that is no concern of yours. In fact, with that single statement you've shown that you are more interested in maintaining power than in running out ICT services.
Maybe not all people are like this. But enough have to have gotten our department to the point of making our staff submit requests to our big boss in detail as to EXACTLY what they want, and let him approve it. The legitimate requests go through and we fill them as soon as they are approved. The no so legitimate ones? They drop it right then and there.
ICT departments are frequently in no position to determine what is legitimate or not.For example, if I am wasting time at work watching porn, then it's my boss's problem, not ICT duty to cut me off because they figure that it must be illegitimate. They should instead simply send the logs to the relevant manager and let him deal with it.
Replace "Porn" with anything else (crapware, slashdot, "illegitimate" software, etc) and the argument still stands.
Uh, what? A VLA is just an area of stack space. When a VLA is created, the top of the stack frame pointer is bumped to accommodate the extra space. When the function returns, the stack pointer is reset to before the current activation record and the VLA becomes invalid. It is exactly as safe as a fixed length allocation on the stack and has exactly the same semantics as a pointer to an object created with alloca.
Your comment about exceptions is pure nonsense. If your C code calls a C++ library, or lives in a library called by C++ and then calls a function pointer back into the application code, then an exception can occur in C, and longjmp can cause exception-like behaviour. In both of these cases, memory from a VLA or allocated with alloca will automatically be freed, but memory allocated with malloc will not. Allocation with malloc is also significantly more expensive, since it requires navigation of a heap and often a system call, while alloca (which is used for VLAs) just needs to add a variable to a pointer. Perhaps a simple illustration would clarify things for you?
int main (void) { int x = foo (); { int i; int array[x]; for (i=0; i<x; i++) { array [i] = i + 12; } for (i=0; i<x; i++) { printf ("%i\n", array [i]); } } return 0; }
The point is that if your allocation fails, there is no way
to determine that it has failed. If you use malloc and
friends they tell you when the allocation has failed. If you
use integer literals, the code always segfaults. If you
use a variable, then the code will segfault only sometime
(when the variable is out of bounds). In the above example,
we cannot know that foo returns a sane value, unless we
range-check the variable before using it.
There is no possible way to check that you have the memory
after requesting it (by the declaration of a VLA). My comment
about exceptions was because a VLA makes perfect sense in
a language that supports exceptions; if there is no more stack
memory - throw an exception. C doesn't let you do that.
IOW, your VLA is only safe if the codes preconditions specify
that the variable may only have a limited range of values. Your code
that uses VLA's is safe if the variables being used go through
a sanity check first, in which case you may as well use pointers.
VLAs are just syntactic sugar on pointers and alloca(). They are fairly trivial to implement, and easier to use safely than alloca(). GCC has supported them for years (and I think even the MS compiler does too), and I've used them in my code.
Then your code is broken. C has no exception handling, and therefore there
is no indication that a VLA is, in fact, valid. Use malloc and friends
if you need VLA's and remember to free them at the end of the block.
It really depends upon who M$ sends to represent them
No, it doesn't. They could always change their representative
when they feel like it. For example, send in a really polite
OS geek who works for Microsoft, then 2 months later replace
him with a Ballmer-wannabe.
Except that's not how you'd do it in most procedural languages today. Instead, you'd define a function and then call that function recursively. Eg, in Python it would be:
def add(x,y): return x+y add(add(1,2),3) 6
So how is that fundamentally different from your Lisp segment, other than you used a built-in function and I created one that mimicked yours?
Your function cannot be curried. Please learn Lisp and/or Haskell before attempting to claim
equivalence.
For every 1 user that is responsible with work resources there are 5 that will do boneheaded things and break something. Then when you want to reimage their computer to fix it they scream and yell that IT is unable to keep their computer working. Those 5 complain to their bosses and so the complaint count is always greater than the happy count. In all likelyhood the 1 person that knows what they are doing also knows that the other 5 are idiots and its pointless to try and argue with them.
Yeah, I hear that a lot from ITC staff. The problem is that the excuse that "we cannot let
the user f**k up their machine because then the user complains about ITC" is bullshit. Either
the user is going to complain that ICT is being less than helpful or they are going to
complain that ICT let them kill their machine. Either way, there is a complaint about ICT.
If ICT really wanted to help the user, then all they have to do is have a policy that
states software requests must be signed by the users manager. This lets the users be accountable
and lets ICT give out the software that is requested. The only reason ICT wants the user to
justify to ICT Staff themselves is because the majority of the staff in ICT have
too much power for their little minds to comprehend.
Prevent users from accessing arbitrary websites because "I say so"? Sure, why not... they
can motivate for wanting access after all. Prevent users from installing software on
their desktop? Excellent, they can motivate if they really need something.
All ICT wants is users grovelling before them, to cope for their own inadequecies. If this
was not the case, then ICT would simply offload the burden of motivation to the users
manager. If the users manager OK's a request, who are ICT to argue?
This is also the primary reason that ICT hate other technical staff (like, developers?)
- we can spot their bullshit a mile off! Even when I provided tcpdump logs (and they provided
nothing) from our department firewall as evidence that some errors on our network
did not originate with our department, they insisted that it must be! The exact words used,
IIRC, were "It must be your firewall, as the download works on this end". It turned out,
after disassembling *their* application, that there was an error in *their* application
that was ip address specific. Really - these people ignored tcpdumps from our firewall
that showed exactly which url was being attempted. How much *more* incompetant can you
get?
Fair enough, not all ICT folk are like this, just like not all lawyers are ambulance
chasers. But enough are that I've given up hope and simply ignore them as much as I can.
The takeaway is this: each cortex does not just do more of the same thing. Instead, it does a refinement of the level below it
You have used 4 paragraphs to describe the word "pipeline".
There is nothing wrong with running things in a pipeline, but it does mean that
all the tasks being submitted to the pipeline are similar (the reason why graphics
processing does so well in a pipelined architecture).
Wrong. See what Head of US Delegation Frank Farance said here
"Eighty percent of the changes were not discussed," said Frank Farance, head of the U.S. delegation [...]
"Virtually every comment we processed did not survive unedited," he said.
Wrong again; 94% of the changes were not discussed!
I'm 25 now, I still play video games, and I played the original Duke Nukem 3D, along with other classics such as Doom I & II, zork, and all those old Sierra adventure games. I'm also engaged right now with a wedding date set for November, and I have a rather nice full time job that pays the bills. Saying or implying anyone over the age of 24 that plays video games has something wrong with them is rather narrow minded. Admittedly I don't play as much as I once did, but I do get a few hours a week in on average.
I'm 29 and still game. I have the whole family, house, and job thing going on, but still find some time to game (not as much as 20 years ago, obviously.) My better half has actually started gaming again, too, which she hasn't done since she was a little girl (she still had her original NES, which works amazing.) We tend to mostly play Wii games together, but she has a DS and I have a ton of other systems (360, PS2, DC, whatever else is in the cellar I haven't dug out since our move.) All the gamers I grew up with still game, and my mother is even still a gamer (and obviously much older than either of us.) I don't think age has a thing to do with it.
Uh, yeah... I'm early thirties, have got a considerably younger hot[1] wife and have had sex 3 times
in the last 3 days...
Obviously, this leaves less time for gaming - but I know what I'd rather be doing:-)
All men regard their wives as "hot" - if they didn't, they wouldn't have married
them, no?
One can only hope that they will be using this to replace the database that comes in Open Office.
Seconded, thoroughly - in addition I would like some decent gui tools for
single-user data-storage requirements; it's annoying that any pc user who
wants to maintain a list of (contacts/friends/must-see-movies/must-read-books/etc)
puts everything into a spreadsheet.
These people should be programming in Python or something where they'd be happier, as would their coworkers.
We sure would;-).
There's nothing wrong with C, except that all forms of declaration and assignment are subtly different and you need to very clear to keep them straight, manually.
Not really; all forms are the ones that make the most sense for the compiler and/or the hardware. Using this
reasoning I was able to infer the behaviour of strncpy(). I could be wrong, but I doubt it. Just the same, I am fairly confident that a struct-to-struct assignment does no deep copies, that simply dereferencing uninitialised
pointers
(without writing to the memory) can cause problems, that using VLA's(c99) is a bad idea, that going 1 past the end
of an array might hurt me, that using gets, even though it is in the standard, is a monumentally stupid idea.
I'm also right alongside the idea that C is not the easiest language, but I still feel that it is a great
teaching language[1] if you want to turn out methodical, careful, cautius and above all, great programmers.
Notes
[1]Sure, programmers should not have to worry about memory; but, like driving a car, the managing of things
like that should come to them after time anyway. Think about learning to drive a manual trans car. You had to
remember to push the clutch in, you had to remember what gear you were in and where the next one (up/down)
was, you had to remember to release the clutch slowly, and to push it back in if you needed to stop, etc.
Now you probably drive without noticing all those things - as a species, we progress by thinking *less*, not more.
We progress but letting our automatic reactions handle those things we previously had to think very hard about.
Managing memory is much the same; I wouldn't trust any programmer who has never spent a good few years in a
non-gc language (ask me why:-)
Slashdot Mirror
Of course *you* wouldn't go for this - it isn't aimed at you, it's aimed at consoler gamers
w00t - I'm on the SA panel
He didn't say "profit" above, he said "income'.
... does he have a script to return the money?
I don't know that I wasn't
Did IT accept to take care of the sewage as well? no? Then they should not have accepted policy which makes them responsible.
Which justifies the assumption that IT is on a power trip.
Face it, if they're power grabbing for priviledges they do not need, it's time to outsource.
Hell no - Every organisation I've worked at in the last twelve years had a *policy*. Not once, in any of my twelve years working both ICT and user, has ICT *ever* been blamed for a user slacking off at work. I'd bet dollars to donuts that your dept. has a policy spelling out that ICT is not liable for anything that the user does (like porn).
"Why was he able to do that, cant you block that stuff?" We had a network manager almost fired because she unblocked someone because they claimed they needed it for a project and in turn was watching KIDDY PORN at work.
Irrelevant if there was a company policy in place. I find it hard to believe that you work at a place that has written policy that blames ICT for the user being able to use the service for illegal activities. No one is getting fired other than the user themselves.
His boss didnt get the axe, SHE almost did. So you can make the claim all you want its not our jobs, but your bosses say otherwise.
Actually, my claim is that it is written down that ICT is not liable - if you work at a place that does not even have a phones/ICT policy, leave. All such policies I've seen make ICT not responsible for anything.
And you should see what middle management approves sometimes. Maybe if we could trust them to approve legitimate packages then sure, but Half Life 2? (true story)
Doesn't matter how true it is - if the users supervisor approved it it's none of your damn business. Your job starts and ends with making sure that the signature is authentic. You are nowhere near knowledgeable nor skilled enough to determine what is legitimate for a user.Once again I must stress - if a user is slacking off, then it's not your job to police that; just inform their manager. Their manager would have to police the users productivity.
Sorry to say in the real world when it comes to computer work, we are as much your boss as your boss is.
Nope - you are sort of proving the theory that ICT prefers to power-grab rather than facilitate. Really, you are in no place to police users - simply tell their managers.If you dont like it, go back to using paper.
And it is this statement that confirms that all you (assuming you are in ICT services at your company) want is more power. Given your relatively clueless attitude about my needs, paper would be preferable. However, the current trend is to simply give less power to ICT to police. If ICT doesn't like what software some user is running, they can simply complain - cutting someone off should be a fireable offence for ICT staff. But the fact is in the nearly 10 years I have been doing this, the user cant be trusted to push the power button, forget about actually making important decisions that could potentially effect other machines.
Likewise, users don't trust ICT services to find a clue with both hands and a map.
Yes, that behaviour can be tuned though - FreeBSD allows tuning knobs for it, IIRC. However the C standard makes it clear that malloc returns NULL on failure - IOW the contract you've got with the hosted C implementation is "as long as the standard is adhered to, the code will work". The developer codes according to the standard and trusts that the implementation is compliant. You are advocating second-guessing the implementation? What if the user of the program turned off lazy allocation?
FWIW, I've not come across a free-standing implementation that uses a lazy allocation scheme.
I only wish!
I have had people at work constantly rag on my department for simular concerns and what does it always turn out to be. We unblock them and instantly the sites like parezhilton and myspace pop on, or the aim client is loaded up, or you find out their request for a certain software program turns out to be a package they have no business running and are scamming their boss into buying for them so they can take it home.
Who determines if the user has any business running a certain piece of software? If their boss approves it, that is no concern of yours. In fact, with that single statement you've shown that you are more interested in maintaining power than in running out ICT services.
Maybe not all people are like this. But enough have to have gotten our department to the point of making our staff submit requests to our big boss in detail as to EXACTLY what they want, and let him approve it. The legitimate requests go through and we fill them as soon as they are approved. The no so legitimate ones? They drop it right then and there.
ICT departments are frequently in no position to determine what is legitimate or not.For example, if I am wasting time at work watching porn, then it's my boss's problem, not ICT duty to cut me off because they figure that it must be illegitimate. They should instead simply send the logs to the relevant manager and let him deal with it.
Replace "Porn" with anything else (crapware, slashdot, "illegitimate" software, etc) and the argument still stands.
Your comment about exceptions is pure nonsense. If your C code calls a C++ library, or lives in a library called by C++ and then calls a function pointer back into the application code, then an exception can occur in C, and longjmp can cause exception-like behaviour. In both of these cases, memory from a VLA or allocated with alloca will automatically be freed, but memory allocated with malloc will not. Allocation with malloc is also significantly more expensive, since it requires navigation of a heap and often a system call, while alloca (which is used for VLAs) just needs to add a variable to a pointer. Perhaps a simple illustration would clarify things for you? The point is that if your allocation fails, there is no way to determine that it has failed. If you use malloc and friends they tell you when the allocation has failed. If you use integer literals, the code always segfaults. If you use a variable, then the code will segfault only sometime (when the variable is out of bounds). In the above example, we cannot know that foo returns a sane value, unless we range-check the variable before using it.
There is no possible way to check that you have the memory after requesting it (by the declaration of a VLA). My comment about exceptions was because a VLA makes perfect sense in a language that supports exceptions; if there is no more stack memory - throw an exception. C doesn't let you do that.
IOW, your VLA is only safe if the codes preconditions specify that the variable may only have a limited range of values. Your code that uses VLA's is safe if the variables being used go through a sanity check first, in which case you may as well use pointers.
Then your code is broken. C has no exception handling, and therefore there is no indication that a VLA is, in fact, valid. Use malloc and friends if you need VLA's and remember to free them at the end of the block.
Off the top of my head - VLA's are difficult to implement and impossible to use safely.
No, it doesn't. They could always change their representative when they feel like it. For example, send in a really polite OS geek who works for Microsoft, then 2 months later replace him with a Ballmer-wannabe.
So how is that fundamentally different from your Lisp segment, other than you used a built-in function and I created one that mimicked yours?
Your function cannot be curried. Please learn Lisp and/or Haskell before attempting to claim equivalence.
Yeah, I hear that a lot from ITC staff. The problem is that the excuse that "we cannot let the user f**k up their machine because then the user complains about ITC" is bullshit. Either the user is going to complain that ICT is being less than helpful or they are going to complain that ICT let them kill their machine. Either way, there is a complaint about ICT.
If ICT really wanted to help the user, then all they have to do is have a policy that states software requests must be signed by the users manager. This lets the users be accountable and lets ICT give out the software that is requested. The only reason ICT wants the user to justify to ICT Staff themselves is because the majority of the staff in ICT have too much power for their little minds to comprehend.
Prevent users from accessing arbitrary websites because "I say so"? Sure, why not
All ICT wants is users grovelling before them, to cope for their own inadequecies. If this was not the case, then ICT would simply offload the burden of motivation to the users manager. If the users manager OK's a request, who are ICT to argue?
This is also the primary reason that ICT hate other technical staff (like, developers?) - we can spot their bullshit a mile off! Even when I provided tcpdump logs (and they provided nothing) from our department firewall as evidence that some errors on our network did not originate with our department, they insisted that it must be! The exact words used, IIRC, were "It must be your firewall, as the download works on this end". It turned out, after disassembling *their* application, that there was an error in *their* application that was ip address specific. Really - these people ignored tcpdumps from our firewall that showed exactly which url was being attempted. How much *more* incompetant can you get?
Fair enough, not all ICT folk are like this, just like not all lawyers are ambulance chasers. But enough are that I've given up hope and simply ignore them as much as I can.
You have used 4 paragraphs to describe the word "pipeline".
There is nothing wrong with running things in a pipeline, but it does mean that all the tasks being submitted to the pipeline are similar (the reason why graphics processing does so well in a pipelined architecture).
"Eighty percent of the changes were not discussed," said Frank Farance, head of the U.S. delegation [...] "Virtually every comment we processed did not survive unedited," he said.
Wrong again; 94% of the changes were not discussed!
"I dunno - how many kinds of idiots are there"
- (Ogre from an episode of Gummi Bears)
I'm 29 and still game. I have the whole family, house, and job thing going on, but still find some time to game (not as much as 20 years ago, obviously.) My better half has actually started gaming again, too, which she hasn't done since she was a little girl (she still had her original NES, which works amazing.) We tend to mostly play Wii games together, but she has a DS and I have a ton of other systems (360, PS2, DC, whatever else is in the cellar I haven't dug out since our move.) All the gamers I grew up with still game, and my mother is even still a gamer (and obviously much older than either of us.) I don't think age has a thing to do with it.
Uh, yeah
Obviously, this leaves less time for gaming - but I know what I'd rather be doing
All men regard their wives as "hot" - if they didn't, they wouldn't have married them, no?
Actually, ISTR seeing this in the fifth elephant - "Every man is a wolf to other men"
???? Whoops - offtopic
I googled for it, but nothing really evil came up
Oh, wait
Seconded, thoroughly - in addition I would like some decent gui tools for single-user data-storage requirements; it's annoying that any pc user who wants to maintain a list of (contacts/friends/must-see-movies/must-read-books/etc) puts everything into a spreadsheet.
--
Homo homini lupus
?Every man is a wolf?
We sure would
Not really; all forms are the ones that make the most sense for the compiler and/or the hardware. Using this reasoning I was able to infer the behaviour of strncpy(). I could be wrong, but I doubt it. Just the same, I am fairly confident that a struct-to-struct assignment does no deep copies, that simply dereferencing uninitialised pointers (without writing to the memory) can cause problems, that using VLA's(c99) is a bad idea, that going 1 past the end of an array might hurt me, that using gets, even though it is in the standard, is a monumentally stupid idea.
I'm also right alongside the idea that C is not the easiest language, but I still feel that it is a great teaching language[1] if you want to turn out methodical, careful, cautius and above all, great programmers.
Notes
[1]Sure, programmers should not have to worry about memory; but, like driving a car, the managing of things like that should come to them after time anyway. Think about learning to drive a manual trans car. You had to remember to push the clutch in, you had to remember what gear you were in and where the next one (up/down) was, you had to remember to release the clutch slowly, and to push it back in if you needed to stop, etc.
Now you probably drive without noticing all those things - as a species, we progress by thinking *less*, not more. We progress but letting our automatic reactions handle those things we previously had to think very hard about. Managing memory is much the same; I wouldn't trust any programmer who has never spent a good few years in a non-gc language (ask me why
Anyway, cheers