Wow, straight out of the marketing literature! Seriously, who other than microsoft would mumble something like "served up securely" when talking about the "cloud"? Only someone from the market department would ever say "knocked it out of the park".
Agreed. Word is a horrible product to use for a thesis. Use the right tool for the job, and MS Office is almost never that tool. Instead it is the "barely good enough" choice that people stick with because they don't know of anything else. On the office people use it because they're addicted to Exchange Server, which means you get Word and Excel as a mere byproduct. Office does not meet good user design guidelines, it's somewhat hostile to the entire notion. Office doesn't even bother with compatibility, in fact it's barely even compatible with itself (since they want the entire world to ugprade in unison, the idea of being compatible with older versions is anathema to Microsoft).
Office is somewhat adequate for writing office memorandums. If that's what someone is writing, then go ahead. If someone is writing something *important*, like a thesis or journal paper, then for heaven's sake use something professional instead of the toy that Microsoft is selling.
You can also continue using LibreOffice and Thunderbird on... Windows! By saying they want to dump those applications, which have the highest compatibility, they're essentially saying that they want to buy in into the classic corporate culture (spend, spend, spend) with no true reason for it except marketing. Meanwhile the classic corporate culture is moving away from a Microsoft monoculture.
I worked one place where a manager said it's a good idea to keep everything because it might need to be subpoenaed someday. I worked a different place where a manager said to purge old stuff because it might need to be subpoenaed someday.
No, many are real. They fool the listener into installing a variant of TeamViewer so that they can remotely control the computer. And my mother nearly fell for this three times. Once was "Microsoft" saying they detected a virus on the computer, but she figured out something was funny and hung up and turned off before too much happened. Second time it was "Best Buy" (actually bestbuy??.us) who called her, shortly after a fake "you've got a virus!" messaged showed up. They offered to help fix her computer, for free. Step one was to remove the old antivirus. Then she bought the new Symantec Endpoint from "Best Buy". Then they ran a virus scan
I was sending some email back and forth and a bit confused by what she was saying, until I got an email update saying "I'll call Microsoft in the morning". So I called and woke her up to get the whole story, explaining that not even the President gets to just call Microsoft and that it was all a scam. She wondered why Best Buy would bother helping her if it was a scam. And she purchased the Symantec Endpoint using a bank transfer number(!!!!). So I had to talk hard to convince her to head to the bank the next day and cancel any transactions, and then monitor every week or so for unusual activity.
Third time it was something similar, only 6 months after the previous thing. She shut off the computer after seeing the mouse moving by itself. Then she got a local guy to remove viruses which he did by wiping the computer, reinstalling windows, and making a huge mess of things (he didn't know there was a backup, she didn't know any of her passwords, and he set her up with a new "free" email account even though the router on the desk should have made it clear she had a paid-for ISP account). I think she was too embarrassed to call me.
Really... when you're young your parents try to teach you beware if strangers. When you get older you have to each your parents to distrust strangers on the internet.
But not suitable for Slashdot where we (should) already know this stuff, there is nothing new here. Slashdot should not be treated as a astroturfing site to garner video reviewers so the author can get a few more pennies from youtube.
And they were awful because they were basically just 8 switches, making them very difficult to use for fine control. The mouse is still digital but it's fine grained enough that it is very handy as an analog approximation, and cheaper than the better joysticks that eventually emerged.
Personally, I think tiny trackball on a controller would have worked well, better overall control while still being usable on the couch or sitting on the living room floor. Takes a few days to get used to perhaps, but controllers take a lot of getting used to also.
I don't understand the concern about mice and keyboards on controllers, except for the paranoids who worry that someone somewhere might be cheating. I thought a big early selling point of xbox was that you could add a mouse and keyboard to it, or extra storage, and move away from the dumbed down consolitus of nintendo and playstation.
A zillion years ago, using a joystick was awful. They were digital devices, not analog, so they'd be move or stop. I only tried using them with flight simulators instead of games that needed aiming. But it was awful. I assume they got better but I always regretted the loss of $15 there. I just never got used to those sorts of controls. Meanwhile I've used a mouse since the eighties and I know how to use it. Gaming console controllers just are not very ergonomic (unless you have tiny hands). The buttons are not where fingers naturally go for instance, and there are a limited number of buttons so you have to learn all sorts of combinations, never mind the absurd circular menu system. It's bad enough that several FPS games I've seen on a console have an auto-aim feature.
A few ways to do it. Not the easiest but they exist. - use an array based tree, which you would see a lot in early algorithm papers or books for languages without pointers. Ie, Node n's children are at 2n+1 and 2n+2. Yes it's cheezy. - use a counter of the depth you are at; print all nodes at depth 1, then all at depth 2, and so forth. Cheezy too and it's O(n^2). - add an extra queue, this is a common approach. If each node already has a next pointer then it's straight forward, but slightly cheezy as it assumes extra storage beyond the stack. - Use a functional language (where there isn't a "stack" per se), and there are some advanced algorithms. But hard to convert to C or Python style.
Embedded systems with a small chip. The default RTOS from the chip maker is often too large, the generic ones are inefficient, etc. For instance we have a demo board from a chip maker, we used their SDK to get things going and are now trying to clean stuff up. We ran out of code space already because their SDK used a nano-libc, brought in floating point, brought in a very bulky printf+console, etc. Writing out own drastically reduces memory usage. We can also use their registers directly and adapt the code into our style of device driver rather than using the somewhat bulky method that the chip maker had in their SDK. We also have to add details that most chip makers don't have in their libraries (low power states).
Also when you're in control of the chip from reset until it gets to main(), you have to know the details of the runtime libary, especially if using C++.
Silos can be a drawback. You often want to have an employee follow a project over its life. If you've got one guy only doing board bring up, then it gets tossed over the fence to application people, you often find a disconnect between competing needs. For example, the drivers used during testing mgiht not be the same drivers used in production which can lead to some subtle problems. Hhaving dealt with a hardware group that tosses boards over the walls and then scrubs their hands of it ("software can make a workaround for all problems") this is a major problem. This doesn't mean that everyone need to know everything, but it would be nice if everyone knew at least two things, or three even. In an *interview* you're going to be asked about things outside of the comfort zone for sure.
Not easily without pulling out proprietary code, and I forget the details. Of course, things CAN be redesigned to avoid it. In this case it seemed more straight forward to just recursively call an earlier function in the call chain (exceptions with unwinding were not available and I think it would have helped in that situation). And it was known that the stack was ok with this case (it had just called a function with even more stack depth requirement). Nothing wrong with it except for the magic word "recursion".
Yes, IF you screw up. If you have very clear and unambiguous exit conditions then you don't screw up. The code is very clear, and yet a code reviewer may say "what if we run out of stack?" even though I proved it isn't a problem.
I see the same thing with loops - programmer insists we must have a loop time out, even if it's reading hardware and the only reason for the loop is to handle clock syncing across domains, and the watchdog is active to handle the case of broken hardware.
I've seen cases where people follow their rules of thumb too rigidly. Ie, put all memory into pools, no exceptions. But then there's a case where I only need some temporary storage to live cross a couple functions, and there is absolutely without a doubt not enough memory if everything is pre-allocated during init. So I use the very tiny seldom used heap for this purpose, allocating the memory only for the duration of the operation. At which point someone complains that I should use a global buffer instead or malloc once only during init. Not because they thought about the issues and debated the various design choices, but because it was a knee jerk response to violating the "use memory pools" guideline.
And yet it gets used in embedded systems with limited stack. Not arbitrary depth recursion of course. But calling the same function twice (with intervening fucntions) is often a convenient and efficient way to do some operations. Ie, start operation, go down a few calls, determine that some storage needs re-arranging before being able to continue, then recursively restart the original function (often optimized away with tail call optimization. I have seen code reviewer gag at that because they're afraid that recursion will go out of control despite the very obvious exit conditions that prove it won't, and they propose a complicated solution that doesn't save any additional memory. (generally the EE people freak out at recursion)
It also means that when you're using functional programming that the programmer with experience knows how to revise the loop to enable the optimization. It's one way you can spot the novice Scheme programmer.
Yes, those are more advanced algorithms. Sometimes you are forced to abandon the first readily elegant solution. But there are often other elegant solutions to investigate. Sorting algorithms for example, on mainframes most of the data would be on mag tapes and the RAM could not hold all that much, so you couldn't use quicksort or heapsort or most certainly not merge sort. But there are other types of sort and if you had a better sort for mainframes then you could make a ton of money (and they did).
If each call of a recursive function requires storage (state variables) then it will use a roughly similar amount of memory storage. Sometimes people avoiding recursion use MORE memory overall as they grab dynamically allocated memory from a heap which has a lot more overhead. Very often recursive programs with the right amount of stack space are smaller and faster than the non-recursive workaround.
If you're on a unix like system, then you can assume your stack is very large, and the OS will allocate or free a new page when necessary, so these often work better than allocating a huge array. Sure, fibonacci in a loop will be more efficient (in C like languages, but in Scheme or Haskell it's more efficient recursively). But a tree walking or graph traversal function is very hard to make as efficient without recursion, and those types of problems are very common.
(I've seen some people link all the nodes in a tree together with forwards/backwards links to avoid recursion even though it is harder to maintain and does not save memory, it's one of those silly tricks that sounds good at first but turns out to be something people will curse at when they try to debug it a few years down the road)
Very often the amount of storage space used by a loop is as much or even more than using the stack. If you've got the stack space, then use it. Less memory used, less code space, less chance of leaked memory. I'm saying this as someone who works on very tiny systems. But too many programmers are stuck with superstitious nonsense, they refuse to use recursion because they heard it was bad but then go and make a huge array to do the same thing with a loop, or they refuse to use GOTO because it makes you go blind but they'll happily use break, return, throw, etc. They'll go and double the code size and make a confusing unmaintainable mess just to avoid some rule of thumb they heard once in school. Yes, the rules of thumb are very good things to follow, but they are not strict taboos they are meant to teach novices to beware of coding horrors like Fortran computed goto spaghetti code.
Slashdot Mirror
Wow, straight out of the marketing literature! Seriously, who other than microsoft would mumble something like "served up securely" when talking about the "cloud"? Only someone from the market department would ever say "knocked it out of the park".
Agreed. Word is a horrible product to use for a thesis. Use the right tool for the job, and MS Office is almost never that tool. Instead it is the "barely good enough" choice that people stick with because they don't know of anything else. On the office people use it because they're addicted to Exchange Server, which means you get Word and Excel as a mere byproduct. Office does not meet good user design guidelines, it's somewhat hostile to the entire notion. Office doesn't even bother with compatibility, in fact it's barely even compatible with itself (since they want the entire world to ugprade in unison, the idea of being compatible with older versions is anathema to Microsoft).
Office is somewhat adequate for writing office memorandums. If that's what someone is writing, then go ahead. If someone is writing something *important*, like a thesis or journal paper, then for heaven's sake use something professional instead of the toy that Microsoft is selling.
You can also continue using LibreOffice and Thunderbird on... Windows! By saying they want to dump those applications, which have the highest compatibility, they're essentially saying that they want to buy in into the classic corporate culture (spend, spend, spend) with no true reason for it except marketing. Meanwhile the classic corporate culture is moving away from a Microsoft monoculture.
I worked one place where a manager said it's a good idea to keep everything because it might need to be subpoenaed someday. I worked a different place where a manager said to purge old stuff because it might need to be subpoenaed someday.
No, many are real. They fool the listener into installing a variant of TeamViewer so that they can remotely control the computer. And my mother nearly fell for this three times. Once was "Microsoft" saying they detected a virus on the computer, but she figured out something was funny and hung up and turned off before too much happened. Second time it was "Best Buy" (actually bestbuy??.us) who called her, shortly after a fake "you've got a virus!" messaged showed up. They offered to help fix her computer, for free. Step one was to remove the old antivirus. Then she bought the new Symantec Endpoint from "Best Buy". Then they ran a virus scan
I was sending some email back and forth and a bit confused by what she was saying, until I got an email update saying "I'll call Microsoft in the morning". So I called and woke her up to get the whole story, explaining that not even the President gets to just call Microsoft and that it was all a scam. She wondered why Best Buy would bother helping her if it was a scam. And she purchased the Symantec Endpoint using a bank transfer number(!!!!). So I had to talk hard to convince her to head to the bank the next day and cancel any transactions, and then monitor every week or so for unusual activity.
Third time it was something similar, only 6 months after the previous thing. She shut off the computer after seeing the mouse moving by itself. Then she got a local guy to remove viruses which he did by wiping the computer, reinstalling windows, and making a huge mess of things (he didn't know there was a backup, she didn't know any of her passwords, and he set her up with a new "free" email account even though the router on the desk should have made it clear she had a paid-for ISP account). I think she was too embarrassed to call me.
Really... when you're young your parents try to teach you beware if strangers. When you get older you have to each your parents to distrust strangers on the internet.
Ironically sarcastic.
But not suitable for Slashdot where we (should) already know this stuff, there is nothing new here. Slashdot should not be treated as a astroturfing site to garner video reviewers so the author can get a few more pennies from youtube.
And they were awful because they were basically just 8 switches, making them very difficult to use for fine control. The mouse is still digital but it's fine grained enough that it is very handy as an analog approximation, and cheaper than the better joysticks that eventually emerged.
Personally, I think tiny trackball on a controller would have worked well, better overall control while still being usable on the couch or sitting on the living room floor. Takes a few days to get used to perhaps, but controllers take a lot of getting used to also.
I don't understand the concern about mice and keyboards on controllers, except for the paranoids who worry that someone somewhere might be cheating. I thought a big early selling point of xbox was that you could add a mouse and keyboard to it, or extra storage, and move away from the dumbed down consolitus of nintendo and playstation.
A zillion years ago, using a joystick was awful. They were digital devices, not analog, so they'd be move or stop. I only tried using them with flight simulators instead of games that needed aiming. But it was awful. I assume they got better but I always regretted the loss of $15 there. I just never got used to those sorts of controls. Meanwhile I've used a mouse since the eighties and I know how to use it. Gaming console controllers just are not very ergonomic (unless you have tiny hands). The buttons are not where fingers naturally go for instance, and there are a limited number of buttons so you have to learn all sorts of combinations, never mind the absurd circular menu system. It's bad enough that several FPS games I've seen on a console have an auto-aim feature.
You must be new to this universe.
A few ways to do it. Not the easiest but they exist.
- use an array based tree, which you would see a lot in early algorithm papers or books for languages without pointers. Ie, Node n's children are at 2n+1 and 2n+2. Yes it's cheezy.
- use a counter of the depth you are at; print all nodes at depth 1, then all at depth 2, and so forth. Cheezy too and it's O(n^2).
- add an extra queue, this is a common approach. If each node already has a next pointer then it's straight forward, but slightly cheezy as it assumes extra storage beyond the stack.
- Use a functional language (where there isn't a "stack" per se), and there are some advanced algorithms. But hard to convert to C or Python style.
And French isn't? French used to be the international language. Or German, which used to be the language of science. Why not Latin?
Esperanto, French, Swahili, even Lojban. Why English of all the languages out there? Parochialism, or Americans too dumb to learn a second language?
Embedded systems with a small chip. The default RTOS from the chip maker is often too large, the generic ones are inefficient, etc. For instance we have a demo board from a chip maker, we used their SDK to get things going and are now trying to clean stuff up. We ran out of code space already because their SDK used a nano-libc, brought in floating point, brought in a very bulky printf+console, etc. Writing out own drastically reduces memory usage. We can also use their registers directly and adapt the code into our style of device driver rather than using the somewhat bulky method that the chip maker had in their SDK. We also have to add details that most chip makers don't have in their libraries (low power states).
Also when you're in control of the chip from reset until it gets to main(), you have to know the details of the runtime libary, especially if using C++.
Silos can be a drawback. You often want to have an employee follow a project over its life. If you've got one guy only doing board bring up, then it gets tossed over the fence to application people, you often find a disconnect between competing needs. For example, the drivers used during testing mgiht not be the same drivers used in production which can lead to some subtle problems. Hhaving dealt with a hardware group that tosses boards over the walls and then scrubs their hands of it ("software can make a workaround for all problems") this is a major problem. This doesn't mean that everyone need to know everything, but it would be nice if everyone knew at least two things, or three even. In an *interview* you're going to be asked about things outside of the comfort zone for sure.
Not easily without pulling out proprietary code, and I forget the details. Of course, things CAN be redesigned to avoid it. In this case it seemed more straight forward to just recursively call an earlier function in the call chain (exceptions with unwinding were not available and I think it would have helped in that situation). And it was known that the stack was ok with this case (it had just called a function with even more stack depth requirement). Nothing wrong with it except for the magic word "recursion".
Yes, IF you screw up. If you have very clear and unambiguous exit conditions then you don't screw up. The code is very clear, and yet a code reviewer may say "what if we run out of stack?" even though I proved it isn't a problem.
I see the same thing with loops - programmer insists we must have a loop time out, even if it's reading hardware and the only reason for the loop is to handle clock syncing across domains, and the watchdog is active to handle the case of broken hardware.
I've seen cases where people follow their rules of thumb too rigidly. Ie, put all memory into pools, no exceptions. But then there's a case where I only need some temporary storage to live cross a couple functions, and there is absolutely without a doubt not enough memory if everything is pre-allocated during init. So I use the very tiny seldom used heap for this purpose, allocating the memory only for the duration of the operation. At which point someone complains that I should use a global buffer instead or malloc once only during init. Not because they thought about the issues and debated the various design choices, but because it was a knee jerk response to violating the "use memory pools" guideline.
And yet it gets used in embedded systems with limited stack. Not arbitrary depth recursion of course. But calling the same function twice (with intervening fucntions) is often a convenient and efficient way to do some operations. Ie, start operation, go down a few calls, determine that some storage needs re-arranging before being able to continue, then recursively restart the original function (often optimized away with tail call optimization. I have seen code reviewer gag at that because they're afraid that recursion will go out of control despite the very obvious exit conditions that prove it won't, and they propose a complicated solution that doesn't save any additional memory. (generally the EE people freak out at recursion)
It also means that when you're using functional programming that the programmer with experience knows how to revise the loop to enable the optimization. It's one way you can spot the novice Scheme programmer.
Yes, those are more advanced algorithms. Sometimes you are forced to abandon the first readily elegant solution. But there are often other elegant solutions to investigate. Sorting algorithms for example, on mainframes most of the data would be on mag tapes and the RAM could not hold all that much, so you couldn't use quicksort or heapsort or most certainly not merge sort. But there are other types of sort and if you had a better sort for mainframes then you could make a ton of money (and they did).
Recursion does not lock you into depth-first traversal. What was your grade in algorithms class?
A topic often overlooked by the average web programmer.
If each call of a recursive function requires storage (state variables) then it will use a roughly similar amount of memory storage. Sometimes people avoiding recursion use MORE memory overall as they grab dynamically allocated memory from a heap which has a lot more overhead. Very often recursive programs with the right amount of stack space are smaller and faster than the non-recursive workaround.
If you're on a unix like system, then you can assume your stack is very large, and the OS will allocate or free a new page when necessary, so these often work better than allocating a huge array. Sure, fibonacci in a loop will be more efficient (in C like languages, but in Scheme or Haskell it's more efficient recursively). But a tree walking or graph traversal function is very hard to make as efficient without recursion, and those types of problems are very common.
(I've seen some people link all the nodes in a tree together with forwards/backwards links to avoid recursion even though it is harder to maintain and does not save memory, it's one of those silly tricks that sounds good at first but turns out to be something people will curse at when they try to debug it a few years down the road)
Very often the amount of storage space used by a loop is as much or even more than using the stack. If you've got the stack space, then use it. Less memory used, less code space, less chance of leaked memory. I'm saying this as someone who works on very tiny systems. But too many programmers are stuck with superstitious nonsense, they refuse to use recursion because they heard it was bad but then go and make a huge array to do the same thing with a loop, or they refuse to use GOTO because it makes you go blind but they'll happily use break, return, throw, etc. They'll go and double the code size and make a confusing unmaintainable mess just to avoid some rule of thumb they heard once in school. Yes, the rules of thumb are very good things to follow, but they are not strict taboos they are meant to teach novices to beware of coding horrors like Fortran computed goto spaghetti code.
Gcc 4.8.4 does put the return address on the stack for everything but a leaf function.