Basically as well as existing antennas. Rain fade happens, pretty much by definition, in all the stuff between the transmitter and the receiver. You can't engineer something in the receiver to make it not happen because it has already happened before the signal gets there.
You can make the antenna bigger to get more signal. That's true with existing technology, that's basically still true with whizzy modern phased array systems. Ideally, the phased array stuff will result in smaller systems with the same ability to pick up signal, so a system with the same size as an existing system but newer technology will probably pick up a faded signal better.
I actually did just read the article and contrary to what many people are posting about, this isn't about data usage and utilization, it's about connectivity utilization and overhead. It seems that similar to opening and closing a database connection there is some overhead in establishing a data connection on a cell phone which is seems is again similar to what happens when you send and SMS. It seems that smart phone development is similar to desktop development in that the application is rarely responsible for creating it's own network connection and instead relies on the OS to handle the network connection. If the phone OS is designed to create and destroy a new data connection for each request then how is that the applications problem. Also, how does a jailbroken iPhone handle data connections differently than a non jailbroken iPhone, the claims made in TFA are just absurd.
If I perform too many search requests in too short a time period on many websites, I get throttled so that i won't overwhelm the database. It seems like the cell network should be able to just ignore devices that go nuts. I mean, it is a public network, so they have to expect some malicious connection attempts and be prepared to deal with them. Focusing only on accidental attack modes seems to ignore the fact that anybody with a tin can and a battery con interact with the network if they get bored or angry.
So back in Oct 2004 would MS have had a working GPU that could do the video encoding? And without one, shouldn't the patent application fail?
If not, I should apply for patents on "a device for the point to point transfer of a physical object without having to cross the intervening space", "a method for corralling future innovation and deriving income without having to perform actual labour" (amongst others).
I hope to hell this patent isn't enforceable in the EU.
I don't know anything about EU law specifically, but in general people do that sort of thing all the time. Patent a handful of promising technologies under the assumption that one of them is bound to turn into something in the near future, then wait to license it to the inventor.
It's rotten, but so is our whole system of IP law. It really disgusts me (as an American) that the US has been so aggressive in promoting the American model to other countries.
The patent application was received in October of 2004 according to the article. So I assume Badaboom would have to precede that or produce some form of prior art preceding that date to defend themselves should Microsoft resort to litigation after failing to agree to a licensing deal with Badaboom's creators. Regardless, a cursory glance proves that Microsoft could out lawyer them whether they are right or not so I believe with a 98% confidence that BadaboomIt is facing some serious liabilities.
The annoying thing is that there won't be a lot of actual prior art to fight the patent. GPU's at that point weren't very good at general purpose computations, so there wasn't a lot of generally available software that did it. Less so for video encoding specifically. OTOH, a GeForce 3 was somewhat programmable and it was released in 2001. People were abusing even simpler GPU's for general purpose computation over ten years ago using texture combiners and compositing modes. Even before then, people used quite general purpose processors as GPU's, and probably could have executed video encoding code on them.
Sadly, despite the fact that if you were to travel back in time to 2003 and shout, "video encoding on the GPU will be practical in a few years," nobody would really be shocked; it is still patentable in our current system because nobody specifically published doing this exact process on this exact type of chip. I expect It'll basically be another land rush of "X on the Internet" and "(The exact same) X on the wireless" type patents on the GPU.
Though, apparently their use of the depth buffer is kind of an interesting hack. That's less obvious from my glance at it, but in what I'd think of as an ideal world, it wouldn't be patentable. It probably doesn't really apply on modern hardware with arbitrary memory buffers and programming in OpenCL. But, it'll still be close enough in behavior to something more sensible on modern hardware that it'll still be scary as part of a giant stack of patents being carried by a scary lawyer looking for rent on your work.
Except trains and planes took people from where they were to where they wanted to go, for traveling between two earth-based locations space is mostly a big detour. We need some targets out there (space stations, moon base, mars base, something) before traveling in space makes any financial sense. In the big picture these people just lift off, circle the landing strip and come back down. They don't go anywhere.
The very first trains were basically just technology demonstrators that didn't go far enough to be particularly useful. Some people found them novel. A few found them to be an interesting implication of what the future would be capable of. A handful decided to invest themselves in building a piece of that future. It took a while before somebody made a train that was commercially significant transportation. It's certainly taken us a lot longer to do something similar with space travel, but every step is getting us closer toward the goal.
100 mbps is enough that downloads are easy to do in the background while you do something else, and have them ready in minutes. A 10GB game can be had in about 15 minutes. You can stream any kind of video you want, even multiple streams. At that speed you could stream 1080p 4:2:2 professional video like you'd put in to a NLE if there were any available on the web.
Something like single-stream ProRes 422 is going to be a lot more than 100 Mbit unless you are using a proxy mode. If "professional" means 10 bit ProRes HQ, you are looking at ~ 220 Mbit per stream.
That aside, your points are certainly broadly valid. Early revolutions are always more shocking than mature revolutions. Enabling a new use is a big deal when almost nothing is possible. Enabling a new use is much less exciting when you can already do a bunch of stuff. We'll always find interesting new uses for whatever bandwidth we've got.
In any case, I think that in the US, the real bandwidth crisis is in upload speeds. They've been practically flat for ten years. To really enable the Next-Gen Buzzword-Compliant Economy-2.0, you need to return to the original peer-centric model of the Internet where every node can act as a host. It's a scary future that neither Telecoms nor Politicians feel comfortable with, but quite frankly I consider it a major strategic requirement for future economic security.
Why the appeal to consensus? This is something I see all the time when it comes to global warming, and it is something that sets off a warning bell. The reasons is that, as Feynman noted, consensus is what salesmen and charlatans use. "4 out of 5 dentists agree that using toothpaste X results in less cavities." Well that is marketing, not science, and in fact doesn't mean much. While it might mean that 20% of dentists are dumb, it might mean to opposite: It might mean 80% of dentists are basing their opinion on something other than the pure facts, while the top 20%, those around a standard deviation or more above the mean, evaluated the facts and found that type of toothpaste was irrelevant.
Consensus isn't so much an argument about climate change, as it is a defense against claims from some people that scientists consider climate change to be a particularly controversial subject which lacks consensus.
It's perfectly appropriate to bring up a fact in response to a false claim. As long as some people acting like salesmen with political motivations insist on distorting the reality of the situation by using the opposite of the "toothpaste argument," then it frankly seems like it would be irresponsible to let their claims stand when there is valid evidence to the contrary. Then, once the peripheral untruths like that are corrected, one hopes that you can get to the heart of the issue and start discussing the actual facts of climate change. Unfortunately, the "anti-salesmen" seem to be able to inject so many random spurious arguments into the discussion that the scientific community is perpetually trying to correct a range of peripheral falsehoods, and is almost never able to actually effectively communicate with the public regarding the meat of climate change, and where the genuine controversies are. (Which are relatively minor things, just like there are some actual scientific controversies in evolution like the exact significance of the role of group selection.)
Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.
Agreed that providing a great GUI can be very hard. A less widely considered issue is that creating a great CLI based system is generally also very hard, and requires just as much consideration and conceptual design work as a great GUI. In some cases, even moreso. The biggest difference is that a poorly designed GUI tends to be useless for what you need to do, while a poorly designed non-graphical UI tends to merely be inconvenient.
In the context of GUI vs. CLI, I think another thing to keep in mind is the nature of what you do with it. Setting up a router allows you to make essentially arbitrary decisions about each packet. On some level, it really is programming, even if the tools you use to do it aren't guaranteed to be Turing complete. You need to describe a behavior, and GUI's are terrible for that sort of thing. While GUI's are bad as a means of expression when you want to describe a behavior, they tend to be quite good for doing specific tasks.
Turn on a default firewall configuration. That's a task. It can map sensible to a button or a checkbox in a GUI. Forward a port to a specific machine. That's also a specific task. It can sensibly by accomplished using a simple GUI with a few buttons, and text entry fields. Set up a router. That's an incredibly vague task. There isn't a fixed set of steps for doing it. In the general case, you need to describe the complete and arbitrary behavior. You need a language for that, and there's no obvious reason to think that a purely visual/spatial "language" will be the most suited. OTOH, a text based language is obviously suited to describing things. That's why we use text to describe the behaviors of programs that we write. iptables isn't a particularly natural or intuitive language, but for doing anything 'interesting,' it's miles ahead of having to do a complicated dance of button presses and repetitions and gestures.
I think if most Linux GUI admin tools tried to focus on being an efficient tool for accomplishing a specific, well defined action, instead of trying to be a complete means of expressing fairly arbitrary behaviors, they would be a lot more useful, despite being more limited in scope.
*Obviously, TFA talks about cisco routers, and I talk about iptables. I don't have as much experience routing with cisco as I do with Linux, so I speak about my own experiences. The author and I seem to have somewhat different backgrounds, but have come to basically equivalent conclusions about the importance of a command line when doing routing work in general. My point isn't about iptables, or routing, as much as it is about explaining behavior of an arbitrarily complex system, and TFA's author and I simply coincidentally happen to both agree that routers are an clear example of this.
The last Microsoft product I bought was Windows 98, so I have mercifully missed the whole disaster since then. All my clients are just now starting to switch from XP to Windows 7, because I advised against Vista. And in all these years of supporting dozens of computers I have never heard of PowerShell until this article. It's nice to hear that Microsoft is starting to do what I did on Unix in 1980. Too bad they did not build on Xenix, and save everyone much grief. Imagine where Apple could have been in the 90s, had they switched to Unix a decade earlier.
Re: Apple switching to Unix a decade earlier. Apple HAd A/UX out by 1988, so that would have required them releasing a Unix for their machines by 1978, prior to releasing the Apple II+.
Depending on where exactly you considered it "released," OS-X was out by 2001. A decade earlier would have meant they needed to make a user friendly Unix Desktop run on a 68030 with 1 MB RAM and a 40 MB Hard drive, with plenty of room left for running Applications, and full compatibility for the existing Mac software.
Yes, NeXT had Unix workstations performing admirably in that era, but for thousands of dollars more than a Macintosh, with much higher base system configurations, and ultimately it proved to be a flop. Nobody needed what NeXT was selling at that point.
For better or worse, the personal computer revolution was made possible by really shitty operating systems. They did the things that people needed at the time, and they did so with sufficiently modest system requirements that you still had plenty of RAM left over for your word processor or flying toasters or whatever. It took a long time before "staying out of the way" was no longer the primary technical selling point for the OS in a personal computer. Once we all had tens of Megabytes of RAM, the benefits of a more sophisticated kernel (whether Linux, Be, NT, or the Mach/OS-X kernel, or any other sensible favorite you might have) suddenly seemed obvious and outweighed the cost of making some of the traditional hacks impossible. (Ordinary user programs writing directly to hardware, one application trivially modifying data in the address space that belonged to another app, etc., all became obsolete.)
Honestly, Apple couldn't have migrated from classic Mac OS to Mac OS X much faster than it did without killing itself. In retrospect, it seems so obviously the right thing that it seems like it shouldn't have been difficult or scary. In some sense, it's kind of amazing that they pulled it off as well as they did. Of course, the great irony of the fact that Apple spent so long hampered by the fact that they weren't really shipping machines that made migrating to more sophisticated technologies practical, is the fact that they ultimately released a telephone running the same OS that was so hard to put in place on the desktop. (With the benefit of not needing to migrate ancient software from a legacy platform -- the problem that ultimately killed Palm when they tried to engage in an analogy of the success of OS-X.)
As for PowerShell, I'm surprised you haven't heard of it. I'm not surprised you haven't run into anybody using it. Classic MS "NIH" + "Make it More Sophisticated" syndromes. They took the OCD-ish elegance of piping text around on the Unix style command line, added some.Net, and made something so much more sophisticated than Bash, and so much more conceptually interesting than Bash, that it's not particularly convenient to use, and a lot of people are just sort of expecting MS to invent yet another new technology to replace it in a few years as part of a marketing campaign, which they tend to do ever now and then.
For the most part, I can confirm that, but there was an 18+ hour period where a percentage of my queries simply reported that Mike Muss was unknown. Odd.
Most of us lived at least a large part of our lives without any root servers - or any servers at all. It's not the end of the world if DNS goes down. It will be ok, I promise.
You are an idiot.
At one time it wouldn't have been a disaster for DNS to go down. Now we have everything from business to business transactions to stock trading to government bonds to consumer purchases being done online. We have hospitals depending on the internet to get their plasma on time. We have a billion people using social networks for hours. We have farmers using the internet to check the weather, militaries using the internet to transmit vital intelligence, and kids using the internet to call home and say they'll be late.
Meh. It's just one of 13 roots. Almost nobody queries it directly. If I have my DNS pointing to my ISP DNS, or to Google DNS, or to my own recursive caching DNS Server which uses one of those as an upstream, all 13 root servers could be down for literally days and it's likely that almost nobody would ever notice. Most DNS servers will retain large caches of most domains. If something freaks out when the roots disappear, a few small ISP's might need to make some quick configuration changes. Some DNS changes wouldn' propagate properly until the DNS root servers were back online. But, frankly, life would go on. Making all of DNS go away would be pretty much impossible, short of taking out every node on the Internet.
Yes, if *All 13* root servers suddenly died, there would be a few people who would get a late night at the office, but I certainly wouldn't see the effects directly.
I wouldn't be surprised if Israel really DID organize Stuxnet, and the date hidden in the code DID mean something, but whoever put it in there was referring to a completely different obscure historical event.
I'm on the same boat. Attributing specific meaning to a date without more information is basically the same game as reading the bible codes, or guessing possible meanings of something encrypted with a one time pad. It can make for an entertaining party game, but it isn't a source of new information in itself. It could just as well be the day the author was born, or the day his father proposed to his mother, or the day his favorite pet goldfish died, or anything else that an outsider with no contextual knowledge could ever accurately figure out. Maybe his cousin just wrote a screenplay that happened to take place on that day for no particular reason, so the author mentioned it as part of a viral marketing campaign. (groan)
I use the keyboard on my phone all the time to send messages that are textual, but it's almost always for gmail chat, skype chat, or AIM. All of those are free, so I have no interest in spending a few dollars a month to get a plan that lets me do what I am basically already doing, but can't easily do from my PC as well. Can't say that I see any value in it.
You can bind specific processes to specific cores. The exact methodology will vary depending on the OS you are using, but just bind all of your VM's to only even numbered cores and you should be able to bypass any problems with HyperThreading. Though, honestly, HT generally doesn't hurt performance. I'd be curious to know how you have measured the performance drop, and what exactly led to the conclusion that HyperThreading was specifically the culprit. There may potentially be some issue with you analysis method.
Linux sucks, but it's okay because Windows sucks too? Great reasoning. I look forward to using it to convince people to switch.
Meh. Do you make your living from convincing people to switch from Windows to Linux? Does it really matter to you what other people use? As far as I'm concerned, Linux just needs to suck less than Windows, which it does. As long as that remains true, I won't have to worry about the hassle of considering migrating everything I do to Windows.
Densities are fine. The main problem is lowering the cost. They need to drop the price by an order of magnitude. I am sure it costs way less than that to manufacture.. they just have to pay back all the research and equipment capital costs and build more production lines.
Density = Cost
The more bits per cm^2 of silicon, the less silicon you need to buy in order to store your stuff. When people talk about density, they aren't talking about the physical size of the consumer SSD product, they mean density of feature size on the silicon chips. It's expensive to refine, process, and manufacture super high end silicon. That's why flash tends to scale quite linearly with storage size in a way that mechanical drives never have. The price really is dominated in a large way by the amount of silicon, which dictates the number of bits. To drive down the price, put more bits on less silicon, and you have a winner.
Other options, like figuring out how to use shittier silicon in cheaper fabs to drive down price are also worth some R+D, but density is the proven method for driving down the price.
Make each test distinct, choose a throwaway question that you know there are online resources to utilize that would answer it.
Have the network operations guys gather proxy info during the exam period. Track anybody who connects to that site (or one of it's ilk) and match it to their distinct question. Give them an F no questions asked and refer to the ethics board for cheating.
You don't have to beat the technology, you just have to catch them when they do what they know is wrong.
How does this help for cell phones? The school's network ops team can't log what doesn't go over their network. Then, you've still got to deal with matching whose device corresponds to which log entry, etc. Depending on how the wireless is set up, that may be impossible, and one teacher gicing a test won't be able to get it changed on his own authority.
AFAIK, cooked meat actually is a lot easier to digest. Also, the argument that raw vegetables are more nutritious ignored the fact that the nutrients tend to be more bioavailable after cooking. So, while cooking may destroy some nutrients, it also unlocks a lot more so that your body generally winds up being better nourished by the "nutrient-poor" cooked version. See how long you can live on raw potato if you don't believe me. I imagine you'd give up pretty quick. (Even ignoring the taste.) OTOH, a human can live for a decent amount of time on cooked potatoes.
Re:Here I was thinking HDR video was old hat
on
HDR Video a Reality
·
· Score: 1
Wouldn't beam-split remove any time differential, making fast-motion HDR video theoretically perfect? I mean, if you're doing time-slices, you could have subject movement in that slice, right?
The spheron style camera doesn't do time slices. It just has a sensor that is specially engineered to have as much dynamic range as a multi-exposure HDR on a traditional sensor would. It's pretty cool. I couldn't begin to explain exactly how they pull it off in the details of the sensor engineering, but I was pretty damned impressed by the demo.
32-bit addressing was seriously impressive in 1987, compared to Acorn's then-current machine with 32KB, including video memory. But now even smartphones are starting to come with 512MB, 1GB of memory. Does ARM have a strategy for getting past 4GB?
From what I understand, the A15 will support 40 bit physical addressing. So far, I'm not certain if that's segmented, or sane. I heard a claim that in a multicore setup, different cores might be configured with distinct memory controllers so that the various cores need not address strictly the same 40b worth of memory, enabling some sort of NUMA setup. Dunno if that will ever happen in practice. 1 TB RAM is likely to be sufficient for the commercially relevant life of the CPU.
Re:Here I was thinking HDR video was old hat
on
HDR Video a Reality
·
· Score: 2, Interesting
Spheron had an awesome single-sensor HDR video camera demo at SIGGRAPH this year. It records 20 stops of latitude, and after some processing for debayering and whatnot, you get an EXR sequence. I got to see it live, in person, and stand a few feet away from the camera. The guy running the demo even let me play with some footage in Nuke on the demo laptop. I'm confused about why a hacked up beamsplitter based system would be so noteworthy, when the single-sensor method will suffer less light loss thanks to the simpler optical path.
I'm sure the guys who did this project are proud of what they pulled off, and it's probably a neat hack, but I have to assume they are sort of operating in a vacuum if they think they have really invented something newsworthy.
That actually covers a lot of culinary territory, but do note that baking and simple pasta dishes just don't cut it.
You can do a macaroni and cheese that doesn't violate your sense of manliness while still being elevated above mere bachelor chow by making a béchamel sauce with a fancy imported cheese. Hit's exemptions 4 and 5 on your list, and for bonus points you can tell a manly story about the culture associated with the cheese. Use Russian sulguni cheese, and you can tell a story about the Russian stripper with the crazy ex boyfriend that you had to beat up, or whatever. Use a French cheese and tell about the world savate champion you used to hang out with, and the time the two of you were in a bar fight against a bunch of bad dudes, etc. If you wear an eye patch for dinner, you can claim that the story related to the cheese has something to do with when your eye was plucked out. It also works if you don't bother to wear an eye patch.
"they are the guys who have supplied Apple with their iPhone baseband chips since 2007."
Does that really mean they're important, though?
Not in isolation, no. It is, OTOH, an example of a very high profile contract, which suggests that they are sufficiently stable in the rest of their business that Apple would be willing to trust doing business with them, without having to fear them suddenly going bankrupt and cutting off supply of a key part. Given that the company is important enough that it would be impossible to list every example of a device that uses an Infineon chip in tfS, the iPhone was probably the most effective example to use.
Slashdot Mirror
Basically as well as existing antennas. Rain fade happens, pretty much by definition, in all the stuff between the transmitter and the receiver. You can't engineer something in the receiver to make it not happen because it has already happened before the signal gets there.
You can make the antenna bigger to get more signal. That's true with existing technology, that's basically still true with whizzy modern phased array systems. Ideally, the phased array stuff will result in smaller systems with the same ability to pick up signal, so a system with the same size as an existing system but newer technology will probably pick up a faded signal better.
If I perform too many search requests in too short a time period on many websites, I get throttled so that i won't overwhelm the database. It seems like the cell network should be able to just ignore devices that go nuts. I mean, it is a public network, so they have to expect some malicious connection attempts and be prepared to deal with them. Focusing only on accidental attack modes seems to ignore the fact that anybody with a tin can and a battery con interact with the network if they get bored or angry.
I don't know anything about EU law specifically, but in general people do that sort of thing all the time. Patent a handful of promising technologies under the assumption that one of them is bound to turn into something in the near future, then wait to license it to the inventor.
It's rotten, but so is our whole system of IP law. It really disgusts me (as an American) that the US has been so aggressive in promoting the American model to other countries.
Tuttle, or was it Buttle? Anyhow, clearly a rogue handyman on the loose. Better arrest somebody.
The annoying thing is that there won't be a lot of actual prior art to fight the patent. GPU's at that point weren't very good at general purpose computations, so there wasn't a lot of generally available software that did it. Less so for video encoding specifically. OTOH, a GeForce 3 was somewhat programmable and it was released in 2001. People were abusing even simpler GPU's for general purpose computation over ten years ago using texture combiners and compositing modes. Even before then, people used quite general purpose processors as GPU's, and probably could have executed video encoding code on them.
Sadly, despite the fact that if you were to travel back in time to 2003 and shout, "video encoding on the GPU will be practical in a few years," nobody would really be shocked; it is still patentable in our current system because nobody specifically published doing this exact process on this exact type of chip. I expect It'll basically be another land rush of "X on the Internet" and "(The exact same) X on the wireless" type patents on the GPU.
Though, apparently their use of the depth buffer is kind of an interesting hack. That's less obvious from my glance at it, but in what I'd think of as an ideal world, it wouldn't be patentable. It probably doesn't really apply on modern hardware with arbitrary memory buffers and programming in OpenCL. But, it'll still be close enough in behavior to something more sensible on modern hardware that it'll still be scary as part of a giant stack of patents being carried by a scary lawyer looking for rent on your work.
The very first trains were basically just technology demonstrators that didn't go far enough to be particularly useful. Some people found them novel. A few found them to be an interesting implication of what the future would be capable of. A handful decided to invest themselves in building a piece of that future. It took a while before somebody made a train that was commercially significant transportation. It's certainly taken us a lot longer to do something similar with space travel, but every step is getting us closer toward the goal.
Something like single-stream ProRes 422 is going to be a lot more than 100 Mbit unless you are using a proxy mode. If "professional" means 10 bit ProRes HQ, you are looking at ~ 220 Mbit per stream.
That aside, your points are certainly broadly valid. Early revolutions are always more shocking than mature revolutions. Enabling a new use is a big deal when almost nothing is possible. Enabling a new use is much less exciting when you can already do a bunch of stuff. We'll always find interesting new uses for whatever bandwidth we've got.
In any case, I think that in the US, the real bandwidth crisis is in upload speeds. They've been practically flat for ten years. To really enable the Next-Gen Buzzword-Compliant Economy-2.0, you need to return to the original peer-centric model of the Internet where every node can act as a host. It's a scary future that neither Telecoms nor Politicians feel comfortable with, but quite frankly I consider it a major strategic requirement for future economic security.
Consensus isn't so much an argument about climate change, as it is a defense against claims from some people that scientists consider climate change to be a particularly controversial subject which lacks consensus.
It's perfectly appropriate to bring up a fact in response to a false claim. As long as some people acting like salesmen with political motivations insist on distorting the reality of the situation by using the opposite of the "toothpaste argument," then it frankly seems like it would be irresponsible to let their claims stand when there is valid evidence to the contrary. Then, once the peripheral untruths like that are corrected, one hopes that you can get to the heart of the issue and start discussing the actual facts of climate change. Unfortunately, the "anti-salesmen" seem to be able to inject so many random spurious arguments into the discussion that the scientific community is perpetually trying to correct a range of peripheral falsehoods, and is almost never able to actually effectively communicate with the public regarding the meat of climate change, and where the genuine controversies are. (Which are relatively minor things, just like there are some actual scientific controversies in evolution like the exact significance of the role of group selection.)
It's not that we love closed protocols. We don't. We simply hate the phone company more.
Agreed that providing a great GUI can be very hard. A less widely considered issue is that creating a great CLI based system is generally also very hard, and requires just as much consideration and conceptual design work as a great GUI. In some cases, even moreso. The biggest difference is that a poorly designed GUI tends to be useless for what you need to do, while a poorly designed non-graphical UI tends to merely be inconvenient.
In the context of GUI vs. CLI, I think another thing to keep in mind is the nature of what you do with it. Setting up a router allows you to make essentially arbitrary decisions about each packet. On some level, it really is programming, even if the tools you use to do it aren't guaranteed to be Turing complete. You need to describe a behavior, and GUI's are terrible for that sort of thing. While GUI's are bad as a means of expression when you want to describe a behavior, they tend to be quite good for doing specific tasks.
Turn on a default firewall configuration. That's a task. It can map sensible to a button or a checkbox in a GUI. Forward a port to a specific machine. That's also a specific task. It can sensibly by accomplished using a simple GUI with a few buttons, and text entry fields. Set up a router. That's an incredibly vague task. There isn't a fixed set of steps for doing it. In the general case, you need to describe the complete and arbitrary behavior. You need a language for that, and there's no obvious reason to think that a purely visual/spatial "language" will be the most suited. OTOH, a text based language is obviously suited to describing things. That's why we use text to describe the behaviors of programs that we write. iptables isn't a particularly natural or intuitive language, but for doing anything 'interesting,' it's miles ahead of having to do a complicated dance of button presses and repetitions and gestures.
I think if most Linux GUI admin tools tried to focus on being an efficient tool for accomplishing a specific, well defined action, instead of trying to be a complete means of expressing fairly arbitrary behaviors, they would be a lot more useful, despite being more limited in scope.
*Obviously, TFA talks about cisco routers, and I talk about iptables. I don't have as much experience routing with cisco as I do with Linux, so I speak about my own experiences. The author and I seem to have somewhat different backgrounds, but have come to basically equivalent conclusions about the importance of a command line when doing routing work in general. My point isn't about iptables, or routing, as much as it is about explaining behavior of an arbitrarily complex system, and TFA's author and I simply coincidentally happen to both agree that routers are an clear example of this.
Re: Apple switching to Unix a decade earlier. Apple HAd A/UX out by 1988, so that would have required them releasing a Unix for their machines by 1978, prior to releasing the Apple II+.
Depending on where exactly you considered it "released," OS-X was out by 2001. A decade earlier would have meant they needed to make a user friendly Unix Desktop run on a 68030 with 1 MB RAM and a 40 MB Hard drive, with plenty of room left for running Applications, and full compatibility for the existing Mac software.
Yes, NeXT had Unix workstations performing admirably in that era, but for thousands of dollars more than a Macintosh, with much higher base system configurations, and ultimately it proved to be a flop. Nobody needed what NeXT was selling at that point.
For better or worse, the personal computer revolution was made possible by really shitty operating systems. They did the things that people needed at the time, and they did so with sufficiently modest system requirements that you still had plenty of RAM left over for your word processor or flying toasters or whatever. It took a long time before "staying out of the way" was no longer the primary technical selling point for the OS in a personal computer. Once we all had tens of Megabytes of RAM, the benefits of a more sophisticated kernel (whether Linux, Be, NT, or the Mach/OS-X kernel, or any other sensible favorite you might have) suddenly seemed obvious and outweighed the cost of making some of the traditional hacks impossible. (Ordinary user programs writing directly to hardware, one application trivially modifying data in the address space that belonged to another app, etc., all became obsolete.)
Honestly, Apple couldn't have migrated from classic Mac OS to Mac OS X much faster than it did without killing itself. In retrospect, it seems so obviously the right thing that it seems like it shouldn't have been difficult or scary. In some sense, it's kind of amazing that they pulled it off as well as they did. Of course, the great irony of the fact that Apple spent so long hampered by the fact that they weren't really shipping machines that made migrating to more sophisticated technologies practical, is the fact that they ultimately released a telephone running the same OS that was so hard to put in place on the desktop. (With the benefit of not needing to migrate ancient software from a legacy platform -- the problem that ultimately killed Palm when they tried to engage in an analogy of the success of OS-X.)
As for PowerShell, I'm surprised you haven't heard of it. I'm not surprised you haven't run into anybody using it. Classic MS "NIH" + "Make it More Sophisticated" syndromes. They took the OCD-ish elegance of piping text around on the Unix style command line, added some .Net, and made something so much more sophisticated than Bash, and so much more conceptually interesting than Bash, that it's not particularly convenient to use, and a lot of people are just sort of expecting MS to invent yet another new technology to replace it in a few years as part of a marketing campaign, which they tend to do ever now and then.
For the most part, I can confirm that, but there was an 18+ hour period where a percentage of my queries simply reported that Mike Muss was unknown. Odd.
Meh. It's just one of 13 roots. Almost nobody queries it directly. If I have my DNS pointing to my ISP DNS, or to Google DNS, or to my own recursive caching DNS Server which uses one of those as an upstream, all 13 root servers could be down for literally days and it's likely that almost nobody would ever notice. Most DNS servers will retain large caches of most domains. If something freaks out when the roots disappear, a few small ISP's might need to make some quick configuration changes. Some DNS changes wouldn' propagate properly until the DNS root servers were back online. But, frankly, life would go on. Making all of DNS go away would be pretty much impossible, short of taking out every node on the Internet.
Yes, if *All 13* root servers suddenly died, there would be a few people who would get a late night at the office, but I certainly wouldn't see the effects directly.
I'm on the same boat. Attributing specific meaning to a date without more information is basically the same game as reading the bible codes, or guessing possible meanings of something encrypted with a one time pad. It can make for an entertaining party game, but it isn't a source of new information in itself. It could just as well be the day the author was born, or the day his father proposed to his mother, or the day his favorite pet goldfish died, or anything else that an outsider with no contextual knowledge could ever accurately figure out. Maybe his cousin just wrote a screenplay that happened to take place on that day for no particular reason, so the author mentioned it as part of a viral marketing campaign. (groan)
I use the keyboard on my phone all the time to send messages that are textual, but it's almost always for gmail chat, skype chat, or AIM. All of those are free, so I have no interest in spending a few dollars a month to get a plan that lets me do what I am basically already doing, but can't easily do from my PC as well. Can't say that I see any value in it.
You can bind specific processes to specific cores. The exact methodology will vary depending on the OS you are using, but just bind all of your VM's to only even numbered cores and you should be able to bypass any problems with HyperThreading. Though, honestly, HT generally doesn't hurt performance. I'd be curious to know how you have measured the performance drop, and what exactly led to the conclusion that HyperThreading was specifically the culprit. There may potentially be some issue with you analysis method.
Meh. Do you make your living from convincing people to switch from Windows to Linux? Does it really matter to you what other people use? As far as I'm concerned, Linux just needs to suck less than Windows, which it does. As long as that remains true, I won't have to worry about the hassle of considering migrating everything I do to Windows.
Density = Cost
The more bits per cm^2 of silicon, the less silicon you need to buy in order to store your stuff. When people talk about density, they aren't talking about the physical size of the consumer SSD product, they mean density of feature size on the silicon chips. It's expensive to refine, process, and manufacture super high end silicon. That's why flash tends to scale quite linearly with storage size in a way that mechanical drives never have. The price really is dominated in a large way by the amount of silicon, which dictates the number of bits. To drive down the price, put more bits on less silicon, and you have a winner.
Other options, like figuring out how to use shittier silicon in cheaper fabs to drive down price are also worth some R+D, but density is the proven method for driving down the price.
How does this help for cell phones? The school's network ops team can't log what doesn't go over their network. Then, you've still got to deal with matching whose device corresponds to which log entry, etc. Depending on how the wireless is set up, that may be impossible, and one teacher gicing a test won't be able to get it changed on his own authority.
AFAIK, cooked meat actually is a lot easier to digest. Also, the argument that raw vegetables are more nutritious ignored the fact that the nutrients tend to be more bioavailable after cooking. So, while cooking may destroy some nutrients, it also unlocks a lot more so that your body generally winds up being better nourished by the "nutrient-poor" cooked version. See how long you can live on raw potato if you don't believe me. I imagine you'd give up pretty quick. (Even ignoring the taste.) OTOH, a human can live for a decent amount of time on cooked potatoes.
The spheron style camera doesn't do time slices. It just has a sensor that is specially engineered to have as much dynamic range as a multi-exposure HDR on a traditional sensor would. It's pretty cool. I couldn't begin to explain exactly how they pull it off in the details of the sensor engineering, but I was pretty damned impressed by the demo.
From what I understand, the A15 will support 40 bit physical addressing. So far, I'm not certain if that's segmented, or sane. I heard a claim that in a multicore setup, different cores might be configured with distinct memory controllers so that the various cores need not address strictly the same 40b worth of memory, enabling some sort of NUMA setup. Dunno if that will ever happen in practice. 1 TB RAM is likely to be sufficient for the commercially relevant life of the CPU.
Spheron had an awesome single-sensor HDR video camera demo at SIGGRAPH this year. It records 20 stops of latitude, and after some processing for debayering and whatnot, you get an EXR sequence. I got to see it live, in person, and stand a few feet away from the camera. The guy running the demo even let me play with some footage in Nuke on the demo laptop. I'm confused about why a hacked up beamsplitter based system would be so noteworthy, when the single-sensor method will suffer less light loss thanks to the simpler optical path.
I'm sure the guys who did this project are proud of what they pulled off, and it's probably a neat hack, but I have to assume they are sort of operating in a vacuum if they think they have really invented something newsworthy.
You can do a macaroni and cheese that doesn't violate your sense of manliness while still being elevated above mere bachelor chow by making a béchamel sauce with a fancy imported cheese. Hit's exemptions 4 and 5 on your list, and for bonus points you can tell a manly story about the culture associated with the cheese. Use Russian sulguni cheese, and you can tell a story about the Russian stripper with the crazy ex boyfriend that you had to beat up, or whatever. Use a French cheese and tell about the world savate champion you used to hang out with, and the time the two of you were in a bar fight against a bunch of bad dudes, etc. If you wear an eye patch for dinner, you can claim that the story related to the cheese has something to do with when your eye was plucked out. It also works if you don't bother to wear an eye patch.
Not in isolation, no. It is, OTOH, an example of a very high profile contract, which suggests that they are sufficiently stable in the rest of their business that Apple would be willing to trust doing business with them, without having to fear them suddenly going bankrupt and cutting off supply of a key part. Given that the company is important enough that it would be impossible to list every example of a device that uses an Infineon chip in tfS, the iPhone was probably the most effective example to use.