How is this paper not a scientific approach to empirical data? We have empirical observations of a wide range of animal/human behaviors. The authors propose a toy mathematical model that reproduces key features of several interesting observed behaviors. This is perfectly good science, just like saying "hey, an F=G*m_1*m_2/r^2 force between massive objects recreates the observed motions of the heavenly bodies"
Astrology fits the definition of careful observations, using those observations to explain other observed behavior, and making predictions. Data gathering and theories aren't science by themselves.
--- a predictive, testable mathematical model that can be compared with measurements of the motions and behaviors of actual critters to see how well it works.
Now, with that trailer, you have a definiton of science. "Testable". But, apparently the TFA doesn't include testable hypotheses.
Too many flames in these weekly Wayland discussions and not enough facts (or maybe the facts are downmodded; I've gotten to the point where if I look at a wayland article, I don't read all of the comments).
For comparison, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that it *is* a compositor that provides both window manager functions and some of the functionality of an X server.
Intentionally misstating things rather badly, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.
I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an opengl library that handed X primitives to the X server. With Wayland, you'd apparently have an opengl library that rendered to a buffer and then handed the buffer off to the Wayland compositor.
So, Wayland isn't doing some of the things we'd expect an X server to do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, the FAQ admits this and notes that you'll need an X server in addition to Wayland for the foreseeable future.
However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time wayland gets the buffers, so you now have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient... OTOH, it seems unlikely that apps would include their own rendering code instead of using as library. So, we can hope that the libraries offer both wayland and X backends, I guess.
Not an X server developer nor a Wayland developer. I'm sure I garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the weekly Wayland discussions.
Back in the day, there were programs for MS-DOS (and no doubt other OSes) that would use "low level" access to the floppy drive in an attempt to be able to read any known type of encoding (and filesystem too of course). I recall one that supported dozens or hundreds of formats from various types of PCs and OSes (CP/M boxes, Amigas, Apples, etc). This was a couple of decades ago, so I don't recall the names of the software. I imagine a search would turn some of these up. It'll likely be "shareware" or commercial rather than open source, so if you find one, it'll probably be useful only with a good emulator or real HW and not as a reference.
At any rate, I imagine the various computer history museums have specs, S/W, and H/W and that there are few formats that are truely orphaned.
Todays specs and formats are no doubt even less likely to be lost at it's more common to have computer copies of these and even to publish them than it was in 80's and earlier.
OTOH, as others have noted, the shelf life of some of the older media is getting long in the tooth. I've got a 9-track tape from college that's probably unreadable. (And probably of little interest anyway).
Decades ago, when the first bank ATMs were being marketed, bank managers were skeptical. They thought that customers preferred human tellers and thought that "people are not going to walk up to a machine and use it".
The fact that people often prefer automated systems is *not* evidence that people don't like talking to or interacting with other people. It's evidence that people would rather deal with a robot than deal with a human in a stylized, scripted, robotic interaction. Efficiency, lack of fuss, predictablity, just getting it done, etc FTW!
So, yeah. Automation threatens some roles previously done by humans. Editor as troll?
tl;dr It's often preferable to interact with real automation than humans playing robots.
Well, 110 baud is 110 bits-per-second. If that's not a unit of measure that involves the binary system,... But yeah, the quantities aren't powers of two.
The earliest VM subsystem that I've looked at is the one for Multics in the 80's. What early systems had VM pages that were not multiples of disk sector size? Just curious.
They already do that precrime stuff with people who possess child porn.
That's not pre-crime. It's crime. Having child porn doesn't just mean the viewer might abuse a child in the future. It also means a child was abused to create the images.
There *is* something magical about a 512 byte or 4096 byte sector size.
It may be possible for a hard disk sector size to be 520 bytes, but it's not convenient nor efficient. What computers do with hard disks at the most basic level is to transfer data between memory and disk. Since computers are binary, it only makes sense that the size of "pages" of memory used in virtual memory schemes be a power of two. It's also much simpler and saner if these in-memory pages are a multiple of the sector size.
Similarly, the nature of digital signaling explains why early networking speeds involved powers of two.
No, phone is not a second factor. It's just a different communication channel to send auth data. Still can be cloned by an attacker and auth data intercepted. IOW it's not something you have, it's something that gets sent to you over different channel.
You're arguing that a phone is not a physical object because it can be used to communicate data. By that logic, the RSA secure-id hardware token I have is also not a second facter and would just be a different mechanism to give me auth data that I type into my work's VPN SW in addition to my password. That's bad logic. You're confusing the question of whether or not a phone is an object that may be physically possessed with how that object is used.
As noted at two factor authentication, the three types of factors are knowledge (something you know), possession (something you have), and something you are.
The typical example of "something you know" is, of course, a password.
Both a phone and a physical key are objects. Things you might have. Neither is knowledge. A door key may be used to move tumblers while the phone is used to receive secrets to be echoed back. Note that you're receiving a new secret that you didn't previously *know*. This is quite different than, for example, simply typing in your phone number.
Nor is whether or not something is a physical posession or whether its knowledge related to whether or not it can be compromised. A physical key can be duplicated; a phone can be cloned; either can be stolen. Nor would we bother with using more than one factor if it wasn't possible that factors could be compromised.
However, some attack vectors work by using one type of factor in place of another. For example, say you get the serial number of my hardware token, acquire the algorithm the tokens use to generate changing numbers, and any necessary initial conditions. Some might argue that you're using knowledge to subvert a mechanism designed to require use of a unique physical object. Calling it a virtual duplicate might be more accurate. Still, my physical token remains a physical object; it doesn't disappear in a puff of logic just because you found a way to trick the system is to thinking you had something you don't have.
I suppose the other thing that my bank does is requiring you to enter a generated number (which they provide by SMS or automated call) to a phone number they have on file. The number is only valid for a few minutes (I don't know the actual timeout).
This seems closer to two-factor, except 1) they have the number generator, so it isn't something YOU have and 2) you can tell their log-in site that "this computer is trusted" and you don't have to enter the number again.
That's not just close; it *is* two factor. You have the phone. Well, maybe some guy who took it at gunpoint has it, but it's still a different factor (have) than the password (know).
Yeah, the ability to disable the mailing of numbers by flagging the computer as trusted arguably *does* remove the 2nd factor. However, I imagine that that bank feels that browser or IP fingerprinting still yields a "something you have".
I'm not sure that they're even saying JS is preferred. (Not sure that they aren't because I just skimmed the blog.) However, the whole context might be
"how do I write a GNOME app?".
Only using a single language in noob/intro examples isn't quite the same thing as deprecating other languages...
During the GNOME Developer Experience Hackfest this week, one of the major goals we identified was the need to pick a *single* language to give a simple answer to "how do I write a GNOME app?". [emphasis added]
Why only one?
* It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our maintanence costs and enables us to be vastly more efficient. * It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges. * It provide a coherent and easy-to-follow path for new developers. * It allows us to include the full GNOME framework within the language itself.
But also:
We will continue to write documentation for other languages, but we will also prioritize JavaScript when deciding what to work on.
I wonder how much harder it would be to support LUA, python, tcl, and some of the other common languages. Or whatever comes next...
Good grief. I was on U-Verse briefly in 2008 or 2009 in Houston. We had an outage that IIRC lasted a few days. I don't recall the exact details, but I think it was some sort of DHCP server issue. In addition to apparently not having an architecture that where possible limits the scope of issues to something less than multiple states, it sounds like they haven't even learned from past problems.
Because no matter how low the cost, the number of people who will not pay for the product by using torrents will far exceed the number of people who will pay for the product simply because they can.
On the other hand, the number of people who WILL pay is quite a bit larger than the number who would pay for your out-of-print product that's not available electronically, which is zero.
I'm glad that people are starting to wise up that counting the people who do pay is always, always wiser than counting the people who don't; for so long, so very many copyright holders have been no smarter than that Aesop dog that dropped his bone in the lake.
The folks over at gog.com (once called Good Old Games) also proved that people will pay reasonable prices for old stuff. However, not unsurprisingly, when they first started gog.com, it was apparently a struggle to get vendors to agree to sell DRM-free versions of their out-of-print games.
[ Charged for caps on home wireless internet & no easy way to determine usage & would prefer throttling ]
How much of your own effort do you want to put into it? It's easy to put your own cheap off the shelf router just before the ISP's device and flash it with your own firmware. Look at OpenWRT or one of the other FOSS or commercial firmware router projects. Probably pretty common among/.ers. Since they provide statistics via SNMP, a (free) off-router network monitoring package could provide all sorts of usage graphs. Admittedly, many of these only show past day/week/30 days and not usage since the first of the month. There are a raft of reasons why it's a good idea to deploy one of these, including improved security. Using bandwidth monitoring and iptables to do custom throttling would be feasible, but you might have to build it.
Mercury is nasty?... I still have a few grams of mercury stored for experiments... Why wouldn't I want to be around it? It's stored in sealed glass containers, in secure storage.
You also have to consider the efficiency. Running a 1GW power plant just to light a 100W light bulb a few kilometers away does not seem a good idea.
Yes, it is possible to transfer power without wires - radio has been doing it for a long time (a simple crystal radio set does not need any power other than what it gets from the antenna, but you'd better have some sensitive headphones, a big antenna and a station that is relatively close). The problem is transferring a lot of power efficiently and without huge antennas.
Their claims are apparently that they can achieve better efficiency than had been thought possible.
Anyone who wants us to believe differently should have independently verified proof. If you suspect parlor tricks, it's helpful to have a magician involved in addition to the scientist or engineer. "Extraordinary claims" and all that...
Or maybe a bad summary? Almost 50% loss over a relatively short distance might match the claims of "majority of the power".
And there is my next movie idea. A rogue non-union group of asteroid miners, sick of lousy pay, blue gruel, and malfunctioning sexbots, actually tries to get an asteroid into a weapon-like trajectory in order to hold to Earth ransom for one bazillion, no wait, one gazillion dollars..../p>
They don't need to count the axles every time you pass though every toll booth. Where I'm at, you're not allowed to move your toll tag from one vehicle to another. And of course, when you apply for a tag, you have to specify the license plate and number of axles for each vehicle you want a tag for.
The author of TFA and author of the patent didn't say the same thing at all.
Patent Author
Unfortunately the patent industry relies far too much on *patent* prior art and ignores the vast corpus of *open* material. The result is that many patents look stupid on their face to anybody 'skilled in the art.'
[ emphasis mine ]
Article Author
This is a good point and one we've raised many times before. So many patents that are issued are ridiculed by people actually skilled in the art, demonstrating how they never should have been issued. But because the USPTO focuses much more on "prior art" (i.e., "is this new?" rather than, "is this obvious?") all sorts of obvious stuff gets patented.
No, an API isn't like a phone number. Save phone numbers for the IP address analogies...
Queue car analogy.
An API is like the power socket or lighter socket on a car. They're all the same diameter, all provide 12 volts DC, etc no matter whose car you buy. This means anyone can create or sell a device that "hooks" into the car's power.
The "I" in API is "interface" of course -- An API is a standard for how two separate things talk to each other.
Oracle seems to want to say feel free to build something that plugs into our power socket, but don't you dare build something with a power socket like ours. Hopefully, copyright can't be twisted to allow that.
...doesn't using a multipurpose OS kernel [... ] waste resources?
Most OSes tend to use a very small fraction of the total CPU cycles. Re memory; sure a custom OS might be more efficient than a general purpose OS. But, this device has 128 MB of memory. The first desktop I used to run Dell UNIX SysVR4 and later Linux had only 8 MB. In other words, the Linux OS is only needs a small percentage of this device's memory. And the advantages of using a well known and "good enough" and flexible OS cannot be underestimated -- it's similar to how the availability of UNIX helped multiple different hardware companies come out with their own mini-computers in the 1980s.
Huh? Not allowing a "null" pointer or otherwise illegal pointer value makes no sense. Either the pointer represented by all zeros is a valid pointer or it's an illegal value. If it's not treated as somehow special or illegal, it's by definition valid. Which would not be nearly as useful as having it be illegal. At best, it would be treated like any other random bit pattern in a pointer -- maybe pointing to legal memory and maybe not. In most languages close to assembly, a valid all zeros pointer would probably point to the beginning of memory; in virtual memory systems, it would probably point to the beginning of the process's space. IIRC, Algol had "references" that were not pointers. Actually Algol is the language with pass-by-name and thunking where it's infamously impossible to write a swap(a,b) function that could handle something like swap(A[i], i).
The word reference doesn't always mean exactly the same thing as pointer (See C++). I imagine Hoare did not mean "null pointer" when he said "null reference".
Trivia: Multics had multiple illegal pointers. I think they were 0 for null, -1 for new-process, and -2 for disconnect process. (Terminal login sessions had a single process). The "new_process" command that threw away your (single) munged process and gave you a fresh clean one was implemented in maybe two lines of code looking vaguely like: declare pointer shiva = addr(-1); *shiva = 666;
... He coined these terms — open surface and open core — to describe a continued commingling — or a blurring — of open source and closed source software that lies at the core of the enterprise and the cloud. Open core, or open source, is the existing model in which core features are open source and value-added proprietary commercial software is built on top of it to monetize the technology. The open surface model, Microsoft’s approach, can be done with APIs, protocols and standards, the Microsoft exec said. The two models are coming together nicely.
So... A tivo is "open core" and a MS SMTP gateway is "open surface". I don't think we needed phrases or sound bites to describe the different ways that platforms could use a combination of closed and open source.
Also from TFA:
“Am I saying that openness doesn’t matter in the cloud? No, openness is extremely important [but] I argue that in the cloud the source code is the Terms of Use and the SLA,” Rabellino said, referring to service-level agreements.”
Slashdot Mirror
How is this paper not a scientific approach to empirical data? We have empirical observations of a wide range of animal/human behaviors. The authors propose a toy mathematical model that reproduces key features of several interesting observed behaviors. This is perfectly good science, just like saying "hey, an F=G*m_1*m_2/r^2 force between massive objects recreates the observed motions of the heavenly bodies"
Astrology fits the definition of careful observations, using those observations to explain other observed behavior, and making predictions. Data gathering and theories aren't science by themselves.
--- a predictive, testable mathematical model that can be compared with measurements of the motions and behaviors of actual critters to see how well it works.
Now, with that trailer, you have a definiton of science. "Testable". But, apparently the TFA doesn't include testable hypotheses.
Too many flames in these weekly Wayland discussions and not enough facts (or maybe the facts are downmodded; I've gotten to the point where if I look at a wayland article, I don't read all of the comments).
So, I just spent 5 or 10 minutes skimming the Wayland FAQ and architecture diagram.
For comparison, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that it *is* a compositor that provides both window manager functions and some of the functionality of an X server.
Intentionally misstating things rather badly, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.
I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an opengl library that handed X primitives to the X server. With Wayland, you'd apparently have an opengl library that rendered to a buffer and then handed the buffer off to the Wayland compositor.
So, Wayland isn't doing some of the things we'd expect an X server to do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, the FAQ admits this and notes that you'll need an X server in addition to Wayland for the foreseeable future.
However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time wayland gets the buffers, so you now have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient... OTOH, it seems unlikely that apps would include their own rendering code instead of using as library. So, we can hope that the libraries offer both wayland and X backends, I guess.
Not an X server developer nor a Wayland developer. I'm sure I garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the weekly Wayland discussions.
Back in the day, there were programs for MS-DOS (and no doubt other OSes) that would use "low level" access to the floppy drive in an attempt to be able to read any known type of encoding (and filesystem too of course). I recall one that supported dozens or hundreds of formats from various types of PCs and OSes (CP/M boxes, Amigas, Apples, etc). This was a couple of decades ago, so I don't recall the names of the software. I imagine a search would turn some of these up. It'll likely be "shareware" or commercial rather than open source, so if you find one, it'll probably be useful only with a good emulator or real HW and not as a reference.
At any rate, I imagine the various computer history museums have specs, S/W, and H/W and that there are few formats that are truely orphaned.
Todays specs and formats are no doubt even less likely to be lost at it's more common to have computer copies of these and even to publish them than it was in 80's and earlier.
OTOH, as others have noted, the shelf life of some of the older media is getting long in the tooth. I've got a 9-track tape from college that's probably unreadable. (And probably of little interest anyway).
I prefer tau day as it gives me an excuse to get 2 pies instead of just one.
For the record I only know pi out to 5 significant digits 3.14159
Fourteen digits are given by a mnemonic I learned in grade school:
How I wish I could recollect of circle round the exact relation Archimede(s) unwound.
Just count the letters in each word.
Decades ago, when the first bank ATMs were being marketed, bank managers were skeptical. They thought that customers preferred human tellers and thought that "people are not going to walk up to a machine and use it".
The fact that people often prefer automated systems is *not* evidence that people don't like talking to or interacting with other people. It's evidence that people would rather deal with a robot than deal with a human in a stylized, scripted, robotic interaction. Efficiency, lack of fuss, predictablity, just getting it done, etc FTW!
So, yeah. Automation threatens some roles previously done by humans. Editor as troll?
tl;dr It's often preferable to interact with real automation than humans playing robots.
Well, 110 baud is 110 bits-per-second. If that's not a unit of measure that involves the binary system, ... But yeah, the quantities aren't powers of two.
The earliest VM subsystem that I've looked at is the one for Multics in the 80's. What early systems had VM pages that were not multiples of disk sector size? Just curious.
They already do that precrime stuff with people who possess child porn.
That's not pre-crime. It's crime. Having child porn doesn't just mean the viewer might abuse a child in the future. It also means a child was abused to create the images.
There *is* something magical about a 512 byte or 4096 byte sector size.
It may be possible for a hard disk sector size to be 520 bytes, but it's not convenient nor efficient. What computers do with hard disks at the most basic level is to transfer data between memory and disk. Since computers are binary, it only makes sense that the size of "pages" of memory used in virtual memory schemes be a power of two. It's also much simpler and saner if these in-memory pages are a multiple of the sector size.
Similarly, the nature of digital signaling explains why early networking speeds involved powers of two.
No, phone is not a second factor. It's just a different communication channel to send auth data.
Still can be cloned by an attacker and auth data intercepted.
IOW it's not something you have, it's something that gets sent to you over different channel.
You're arguing that a phone is not a physical object because it can be used to communicate data. By that logic, the RSA secure-id hardware token I have is also not a second facter and would just be a different mechanism to give me auth data that I type into my work's VPN SW in addition to my password. That's bad logic. You're confusing the question of whether or not a phone is an object that may be physically possessed with how that object is used.
As noted at two factor authentication, the three types of factors are knowledge (something you know), possession (something you have), and something you are.
The typical example of "something you know" is, of course, a password.
Both a phone and a physical key are objects. Things you might have. Neither is knowledge. A door key may be used to move tumblers while the phone is used to receive secrets to be echoed back. Note that you're receiving a new secret that you didn't previously *know*. This is quite different than, for example, simply typing in your phone number.
Nor is whether or not something is a physical posession or whether its knowledge related to whether or not it can be compromised. A physical key can be duplicated; a phone can be cloned; either can be stolen. Nor would we bother with using more than one factor if it wasn't possible that factors could be compromised.
However, some attack vectors work by using one type of factor in place of another. For example, say you get the serial number of my hardware token, acquire the algorithm the tokens use to generate changing numbers, and any necessary initial conditions. Some might argue that you're using knowledge to subvert a mechanism designed to require use of a unique physical object. Calling it a virtual duplicate might be more accurate. Still, my physical token remains a physical object; it doesn't disappear in a puff of logic just because you found a way to trick the system is to thinking you had something you don't have.
I suppose the other thing that my bank does is requiring you to enter a generated number (which they provide by SMS or automated call) to a phone number they have on file. The number is only valid for a few minutes (I don't know the actual timeout).
This seems closer to two-factor, except 1) they have the number generator, so it isn't something YOU have and 2) you can tell their log-in site that "this computer is trusted" and you don't have to enter the number again.
That's not just close; it *is* two factor. You have the phone. Well, maybe some guy who took it at gunpoint has it, but it's still a different factor (have) than the password (know).
Yeah, the ability to disable the mailing of numbers by flagging the computer as trusted arguably *does* remove the 2nd factor. However, I imagine that that bank feels that browser or IP fingerprinting still yields a "something you have".
I'm not sure that they're even saying JS is preferred. (Not sure that they aren't because I just skimmed the blog.) However, the whole context might be
"how do I write a GNOME app?".
Only using a single language in noob/intro examples isn't quite the same thing as deprecating other languages...
From the TFA and the blog linked from the TFA:
During the GNOME Developer Experience Hackfest this week, one of the major goals we identified was the need to pick a *single* language to give a simple answer to "how do I write a GNOME app?". [emphasis added]
Why only one?
* It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our maintanence costs and enables us to be vastly more efficient.
* It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges.
* It provide a coherent and easy-to-follow path for new developers.
* It allows us to include the full GNOME framework within the language itself.
But also:
We will continue to write documentation for other languages, but we will also prioritize JavaScript when deciding what to work on.
I wonder how much harder it would be to support LUA, python, tcl, and some of the other common languages. Or whatever comes next...
Good grief. I was on U-Verse briefly in 2008 or 2009 in Houston. We had an outage that IIRC lasted a few days. I don't recall the exact details, but I think it was some sort of DHCP server issue. In addition to apparently not having an architecture that where possible limits the scope of issues to something less than multiple states, it sounds like they haven't even learned from past problems.
Because no matter how low the cost, the number of people who will not pay for the product by using torrents will far exceed the number of people who will pay for the product simply because they can.
On the other hand, the number of people who WILL pay is quite a bit larger than the number who would pay for your out-of-print product that's not available electronically, which is zero.
I'm glad that people are starting to wise up that counting the people who do pay is always, always wiser than counting the people who don't; for so long, so very many copyright holders have been no smarter than that Aesop dog that dropped his bone in the lake.
The folks over at gog.com (once called Good Old Games) also proved that people will pay reasonable prices for old stuff. However, not unsurprisingly, when they first started gog.com, it was apparently a struggle to get vendors to agree to sell DRM-free versions of their out-of-print games.
[ Charged for caps on home wireless internet & no easy way to determine usage & would prefer throttling ]
How much of your own effort do you want to put into it? It's easy to put your own cheap off the shelf router just before the ISP's device and flash it with your own firmware. Look at OpenWRT or one of the other FOSS or commercial firmware router projects. Probably pretty common among /.ers. Since they provide statistics via SNMP, a (free) off-router network monitoring package could provide all sorts of usage graphs. Admittedly, many of these only show past day/week/30 days and not usage since the first of the month. There are a raft of reasons why it's a good idea to deploy one of these, including improved security. Using bandwidth monitoring and iptables to do custom throttling would be feasible, but you might have to build it.
Sorry, bad link; should have been mad as a hatter
Mercury is nasty? ... I still have a few grams of mercury stored for experiments ... Why wouldn't I want to be around it? It's stored in sealed glass containers, in secure storage.
You'll become as mad as a hatter
Apologies for ignoring your "sealed glass container".
You also have to consider the efficiency. Running a 1GW power plant just to light a 100W light bulb a few kilometers away does not seem a good idea.
Yes, it is possible to transfer power without wires - radio has been doing it for a long time (a simple crystal radio set does not need any power other than what it gets from the antenna, but you'd better have some sensitive headphones, a big antenna and a station that is relatively close). The problem is transferring a lot of power efficiently and without huge antennas.
Their claims are apparently that they can achieve better efficiency than had been thought possible.
Anyone who wants us to believe differently should have independently verified proof. If you suspect parlor tricks, it's helpful to have a magician involved in addition to the scientist or engineer. "Extraordinary claims" and all that...
Or maybe a bad summary? Almost 50% loss over a relatively short distance might match the claims of "majority of the power".
And there is my next movie idea. A rogue non-union group of asteroid miners, sick of lousy pay, blue gruel, and malfunctioning sexbots, actually tries to get an asteroid into a weapon-like trajectory in order to hold to Earth ransom for one bazillion, no wait, one gazillion dollars..../p>
Instead of non-union miners, how about prisoners (and their descendants) in a conspiracy with the worlds first AI? http://wikipedia.org/wiki/The_Moon_Is_a_Harsh_Mistress
They don't need to count the axles every time you pass though every toll booth. Where I'm at, you're not allowed to move your toll tag from one vehicle to another. And of course, when you apply for a tag, you have to specify the license plate and number of axles for each vehicle you want a tag for.
The author of TFA and author of the patent didn't say the same thing at all.
Patent Author
Unfortunately the patent industry relies far too much on *patent* prior art and ignores the vast corpus of *open* material. The result is that many patents look stupid on their face to anybody 'skilled in the art.'
[ emphasis mine ]
Article Author
This is a good point and one we've raised many times before. So many patents that are issued are ridiculed by people actually skilled in the art, demonstrating how they never should have been issued. But because the USPTO focuses much more on "prior art" (i.e., "is this new?" rather than, "is this obvious?") all sorts of obvious stuff gets patented.
No, an API isn't like a phone number. Save phone numbers for the IP address analogies...
Queue car analogy.
An API is like the power socket or lighter socket on a car. They're all the same diameter, all provide 12 volts DC, etc no matter whose car you buy. This means anyone can create or sell a device that "hooks" into the car's power.
The "I" in API is "interface" of course -- An API is a standard for how two separate things talk to each other.
Oracle seems to want to say feel free to build something that plugs into our power socket, but don't you dare build something with a power socket like ours. Hopefully, copyright can't be twisted to allow that.
...doesn't using a multipurpose OS kernel [ ... ] waste resources?
Most OSes tend to use a very small fraction of the total CPU cycles. Re memory; sure a custom OS might be more efficient than a general purpose OS. But, this device has 128 MB of memory. The first desktop I used to run Dell UNIX SysVR4 and later Linux had only 8 MB. In other words, the Linux OS is only needs a small percentage of this device's memory. And the advantages of using a well known and "good enough" and flexible OS cannot be underestimated -- it's similar to how the availability of UNIX helped multiple different hardware companies come out with their own mini-computers in the 1980s.
Huh? Not allowing a "null" pointer or otherwise illegal pointer value makes no sense. Either the pointer represented by all zeros is a valid pointer or it's an illegal value. If it's not treated as somehow special or illegal, it's by definition valid. Which would not be nearly as useful as having it be illegal. At best, it would be treated like any other random bit pattern in a pointer -- maybe pointing to legal memory and maybe not. In most languages close to assembly, a valid all zeros pointer would probably point to the beginning of memory; in virtual memory systems, it would probably point to the beginning of the process's space. IIRC, Algol had "references" that were not pointers. Actually Algol is the language with pass-by-name and thunking where it's infamously impossible to write a swap(a,b) function that could handle something like swap(A[i], i).
The word reference doesn't always mean exactly the same thing as pointer (See C++). I imagine Hoare did not mean "null pointer" when he said "null reference".
Trivia: Multics had multiple illegal pointers. I think they were 0 for null, -1 for new-process, and -2 for disconnect process. (Terminal login sessions had a single process). The "new_process" command that threw away your (single) munged process and gave you a fresh clean one was implemented in maybe two lines of code looking vaguely like: declare pointer shiva = addr(-1); *shiva = 666;
...
He coined these terms — open surface and open core — to describe a continued commingling — or a blurring — of open source and closed source software that lies at the core of the enterprise and the cloud.
Open core, or open source, is the existing model in which core features are open source and value-added proprietary commercial software is built on top of it to monetize the technology.
The open surface model, Microsoft’s approach, can be done with APIs, protocols and standards, the Microsoft exec said. The two models are coming together nicely.
So... A tivo is "open core" and a MS SMTP gateway is "open surface". I don't think we needed phrases or sound bites to describe the different ways that platforms could use a combination of closed and open source.
Also from TFA:
“Am I saying that openness doesn’t matter in the cloud? No, openness is extremely important [but] I argue that in the cloud the source code is the Terms of Use and the SLA,” Rabellino said, referring to service-level agreements.”