I almost think they should change the rules to favor the team that's behind to keep the score closer. "Socialized" sports? Worth a try. The main purpose of sports is entertainment anyhow: they are not factories. Blowouts suck, with or without recording
Preventing predictable blowouts is exactly what is behind many of the NFL's policies. Salary caps, player free agency, easier schedules for teams that did poorly the prior year, and better draft picks for teams that did poorly are all designed to make it harder for any team to dominate. The idea is that on "any given Sunday" anyone might win.
Just to play Devil's advocate a bit here, but isn't this exactly the way the system is supposed to work?
No. Period, full stop. Very few think the "system" should gather as much data as possible on as many people as possible. I don't know the U.K. laws, but in the U.S., the authorities aren't allowed to search out whatever they want about you without probable cause and/or warrants.
Having information on someone is what puts them in the "no security interest" category, rather than the "unknown" category. In reviewing that information, crimes like copyright infringement may be discovered, and that puts the person in a different category entirely
So, we should hoover up all the information we can about everyone, so we can be sure we know who would be "of interest"? Cardinal Richelieu would be delighted.
Now, if understand the typical Slashdotter's perspective, the government shouldn't be allowed to gather information on people of "no security interest", but they can't know who that is without gathering information. Naturally, then, we will lobby to prohibit all gathering of information, and when successful, we will mock the government's eventual failure to find people who are of "security interest" with their then-nonexistent capabilities.
Why, yes, most of us on Slashdot use a silly fake paradox to conclude that no investigative effort should ever gather any information. Idiot.
The real question is are you a troll or do you just come from a black and white world?
VOIP and other time-sensitive packets must be prioritized over other packets or performance of those services won't be acceptable to users.
ISPs want to argue that, but it's not as relevant as it looks. Because QOS priorities really only matter if the network is congested. And, the ISP shouldn't have congested backbone links.
The car analogies the ISPs offer up are broken. It's not really about being able to have a faster than *normal* lane. Having a higher QOS priority is more like driving in a normal speed toll lane during rush hour because the the non-toll lanes are congested. But, outside of rush hour, when the non-toll lanes are running just as fast, there's no point to paying to drive in the toll lane. ISPs shouldn't have the congested links that are analogous to the rush hour though.
Much of the ISP's desire to do shaping seems to be about having intentionally under-provisioned links and then either charging a toll to "uncongest" or making a competitor's traffic suffer while the ISP's traffic doesn't.
Abortions are not a right, never were: have been illegal for the past more than 100 years,...
I'm sure you have some lame pseudo-legal argument that you think proves that statement, but you're wrong. Whatever your argument is, it's not something people are actually prosecuted under. Some abortions are legal. If they weren't, all the abortion clinics would have been closed down. The people that want to use the legal system to stop abortions are finding other ways. They do things like passing the recent Texas law that required that abortions only be done in facilities that have more surgical capabilities than is required for other more complex surgical procedures.
No, almost all the posters have it wrong - a carefully done re-implementation can be legit. You can't use the exact same potentially trade-marked names. You can't re-distribute the original art work. But, you can do things like create a new engine and anyone who owns the original game can then re-use the content in the new engine. See the article on Game Engine Recreation or the OpenMW project that's creating a version of the Elder Scrolls III: Morrowind game in a new engine.
That said, I don't know if this Metal Gear Solid remake wasn't careful to follow the rules or if maybe they did, but Konami gave them enough grief to make them stop anyway.
This is asinine.... undercover agent, or something along those lines, leaking that information could make those people or their families vulnerable to kidnapping and violence.
How the hell is that +5 Insightful?!? I seriously doubt undercover FBI agents are using their real names! The only time their real name should come out is sometimes at trial.
Just because you have unauthorized access to do something and you have the skills to do so, that doesn't make it right.
[ Depending on a service offering (especially a dirt cheap one) is a risk ]
Which is why you should use layers of abstraction.
In this example, it would be sensible to support at least two services for back-end data storage. If you want a minimal footprint, you don't even have to ship your mobile app with multiple back-ends enabled (nor the config options to choose a back-end). You'd still be in a position to more quickly provide an update if the service disappears or looks like it's about to.
[...] you also have to create low-cost reusable rockets designed for repeat operation on the moon with little to no maintenance, fueled by materials from the lunar surface. Which is a vastly harder, more expensive task. After all, it makes no financial sense to mine a tonne of water from the surface of the moon and then deliver it into lunar orbit or beyond with 10 tonnes of hardware/propellant sent from Earth, which in turn took 100 tonnes to get off the surface of the Earth. Everything has to be long-term operable entirely in the lunar environment with lunar resources. There's not any realistic budgeting scenario where it's even remotely cheaper, all capital costs included, to get your water from the moon in the remotely near future than to just launch it from the earth on existing rockets.
Electromagnetic mass drivers might make more sense than rockets for launching raw materials from the moon. At least that was what Gerard K. O'Neill and company concluded decades ago... Of course, you still have to build the mass driver on-site or deliver it there and run a mining operation.
I have to think that for sufficiently large scale offworld operations, you're going to want to mine materials from somewhere - either the moon or asteroids. As interesting as the topic is, I don't think we'll be building semi-permanent moon bases, Babylon 5, or mars colonies within ten years though.
[... ] It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in/proc and/dev to get information about the system or make changes to it.
Sure. But is the mapping provided here sane? It makes sense to provide a view of the variables as files. Reading the file should return that variables value. Writing the file should change that variables value. OK, so far.
If deleting the file is to have any effect on the actual UEFI variables, it should mean deleting the variable, not zeroing it. Does deleting UEFI variables from the BIOS even make sense? Note that for/dev, the files represent read/write/ioctl access to a device but that deleting a/dev file is like deleting a pointer to an object - it removes your pointer but has no effect on the object itself (and any other similar pointers are still usable). I strongly suspect that the filesystem for these variables should work the same way. Even if creating entirely new variables and deleting them from UEFI is a valid thing to do, it probably needs to be done by a mechanism other than filesystem semantics.
C and C++ are only the foundation because the happened to become popular due to a bunch of misc. factors, not because they are inherently great inventions in themselves. [... ]
No, C *was* a great invention. That there are other choices today doesn't change that. It was perhaps the first HLL (high level language) that was small, efficient, and yet also usable for low-level tasks. It was "small" in the sense that that it provided a minimal number of constructs and didn't provide any hard to parse features (unlike, for example, Ada). The fact that it was small was probably a big factor in C having one of the very first machine independent compilers, the Portable C Compiler.
C is a general-purpose, imperative computer programming language, supporting structured programming, lexical variable scope and recursion, while a static type system prevents many unintended operations. By design, C provides constructs that map efficiently to typical machine instructions, and therefore it has found lasting use in applications that had formerly been coded in assembly language, including operating systems, as well as various application software for computers ranging from supercomputers to embedded systems.
[ Vendors ] are designing security into newer protocols...
That's nice... *today*. Well, assuming every protocol someone designs and that someone implements will be free of security flaws... But, "nice today" is not very useful long term.
Imagine, for example, that something is running using Windows XP or a decades old Linux distro. They could have had the best available security when they were built, but they would suck now. A decades old SSH would now be vulnerable.
It seems that historically, sites always end up with some sort of old cruft in existence. As long as you have to account for equipment not being patched or upgraded, the quality of that equipment's security is insufficient. You need layers. Sane physical controls. An architecture of least privilege. You probably want some sort of VPN that has a guarantee of ongoing security maintenance even when everything else doesn't. Even then, the network access should have some of the attributes you'd use in physical controls - you don't let Joe Whoever into just any control room, so *try* to not allow network connection from just anywhere.
Of the above layers, the architecture may be the most important. For example, if it's OK to be air-gapped, that takes a lot of attack vectors off the table.
HTTPS is the only real answer. Rules like what are being proposed are hard to enforce. But properly implemented authentication and encryption will make such rules unnecessary.
Nope.
HTTPS is necessary, but woefully insufficient for protecting your privacy. Even with everything encrypted, your ISP still knows what sites you connect to - they do route the packets, after all. Would it be OK if which ads are displayed on your TV to be affected by which sites you visit? And "you", of course, includes anyone in your household and your WiFi guests. Which snail mail adverts are sent to your billing address or service address? Or, in general, whether or not your name appears on various targeted advertising lists? Or lists that aren't at all about advertising...
A VPN will prevent your ISP from doing this, but then gives your VPN host the same capabilities.
On a similar note, we've had a bunch of articles here about how it's almost impossible to prevent web browser fingerprinting from allowing you to tracked from one web site to another. But, your ISP is in a special position to know all that you visit and who/where "you" are.
... Now you're telling me a company called Internatioal "Business" Machines had some sort of weird 32 bit computer family in the 1960s?
I didn't read TFA, but I'm guessing the 360 was one of the first or second generation of 32-bit machines. Decades ago 32-bit wasn't the thing. A lot of the bigger older machines used 36 bit data types. That allowed integers up to 10 decimal digits long to be represented so that these new electronic computers could compete with the 10 digit mechanical computers that preceded them. Later, the advantages of using powers of two won out over that compatibility.
I skimmed an article about the pinch now hitting higher priority water rights holders while waiting at a doctor's office yesterday. Apparently people and corporations have water rights going back over a hundred years that control who does and does not get water. They still have to pay for it though. Seems like the legalized prioritizations might make a lot of the discussion about what water should and should not be used for moot. Or, as usual, that simplistic solutions aren't feasible.
So, it's exactly like he said and no updates are allowed to be installed.
ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.
Honestly, I hope some hospital gets the balls to sue an ISV for failing to act in a timely manner for perpetually ignoring security like we all know they do. It's not going to change until someone holds them accountable. They'll just hide behind their EULAs until then, and hospitals will get the bill for letting people die because of security holes.
From the linked FDA page:
4. Who is responsible for ensuring the safety and effectiveness of medical devices that incorporate OTS software?
You (the device manufacturer who uses OTS software in your medical device) bear the responsibility for the continued safe and effective performance of the medical device, including the performance of OTS software that is part of the device.1
If the device manufacturers are forcing hospitals to run without OS patches, the manufacturers are not doing what the FDA says they should do. Maybe the FDA should change should to required. Even so, I have to wonder if there's anything preventing the manufacturers from simply maintaining a patch compatibility web page and telling the hospitals that they're responsible for the OS patches... I seriously doubt either party is innocent, but have to wonder if the hospitals are the bigger culprit.
"I'm going to work for the IRS" said no competent, industrious individual. Ever.
Work for? Yes. Stay? No.
An IRS auditor once told me that IRS experience looks great on a resume if you want to work as a tax accountant or similar. He said the job at the IRS wasn't great, but that the experience was valuable. So, he continued, the IRS has lots of turnover.
I've had returns questioned a few times. The above conversation occured when I was working as contracter and the IRS claimed we'd underpaid taxes after they recorded my quarterly estimated taxes to my SSN in their databases and our recorded our *joint* April 15th taxes to my wife's SSN. It took a couple of years to settle IIRC, and it seemed there was a different agent every few months.
I published a project on github a year or couple ago. It is/was in an alpha state and not functional, so there's no huge interest. Figuring out what license to use took some time because of interactions with other efforts. My project makes use of files licensed under the MIT license. I expect to eventually contribute my code to another project that uses what seems to be an ISC license. I need the user to download a library that's only available as source. Not the most complex situation, but researching the license options takes time.
I can imagine that some people want to publish their code, but are either unaware that the default license is "all rights reserved", don't care, or care but don't want to spend the time to figure out what's appropriate.
The default license is "all rights reserved". When you create a new (public) project, github should require you to acknowlege that or to specify a license. A link to a good discussion of licensing issues could be included. The list of licenses to choose from should include "all rights reserved" and "see project-specific license". I'm not sure that "public domain" should be on the list because IIRC you need at least a minimal license to say "no warrenty" and provide a "limitation of liability". Project owners could still leave their code unlicensed.
Seems like a bit of FUD on both sides of the argument...
A while back, I spent a few minutes skimming the Wayland FAQ and Wayland Architecture Diagram. Interesting stuff, especially the architecture page, and they provide actual detail while the TFA mostly doesn't.
For comparison of the two architectures, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that Wayland *is* a compositor that provides both window manager functions and some of the functionality of an X server.
From what I can see, here's the architectual differences between X and Wayland when it comes to supporting remote app display:
Intentionally misstating by being over simplistic, 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 than an X server would 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, both the TFA and the FAQ report this and note that you'll need X server(s) in addition to Wayland for the foreseeable future. The X server(s) talk to Wayland instead of to hardware.
There's going to be support for running Wayland apps remotely. 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 have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient...
The discussion of doing remote Wayland apps seems to revolve around how to transmit the per-app buffers across the network instead of handing the buffer to the local Wayland compositor / display driver. Or perhaps about having the compositor know that certain app buffers should be transmitted instead of composited to the local display, but that's almost the same thing when viewed as a flow.
Transmitting bitmap deltas works pretty well, but for some apps, sending higher level information such as the original OpenGL might be better. With X, they defined an extension, GLX for essentially passing the OpenGL to a remote server. Similarly, I imagine it would be useful if an OpenGL app could talk to a remote Wayland server instead of sending bitmap deltas. So, it looks to me like it would be useful to define an extension mechanism for transport that would allow OpenGL commands to be sent to a remote computer where they could be rendered to a remote buffer and handed off to the remote Wayland compositor. Bonus points if the extension mechanism is generic. Seems like transport of audio might be another fit for a modern replacement of X.
Not an X server developer nor a Wayland developer. I may have garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the
No, the key has to be inside the passenger compartment to start it.
My sister reports that her car started just fine with the keys on the roof or hood. Not that they stayed there after the car started moving...
You already (should) be buckling a seat/shoulder belt. That's more effort than putting a key in a key hole. So, I don't see that the risks of keyless entry *and* starting make up for the minor convenience of not having to use a key. YMMV.
Slashdot Mirror
I almost think they should change the rules to favor the team that's behind to keep the score closer. "Socialized" sports? Worth a try. The main purpose of sports is entertainment anyhow: they are not factories. Blowouts suck, with or without recording
Preventing predictable blowouts is exactly what is behind many of the NFL's policies. Salary caps, player free agency, easier schedules for teams that did poorly the prior year, and better draft picks for teams that did poorly are all designed to make it harder for any team to dominate. The idea is that on "any given Sunday" anyone might win.
Just to play Devil's advocate a bit here, but isn't this exactly the way the system is supposed to work?
No. Period, full stop. Very few think the "system" should gather as much data as possible on as many people as possible. I don't know the U.K. laws, but in the U.S., the authorities aren't allowed to search out whatever they want about you without probable cause and/or warrants.
Having information on someone is what puts them in the "no security interest" category, rather than the "unknown" category. In reviewing that information, crimes like copyright infringement may be discovered, and that puts the person in a different category entirely
So, we should hoover up all the information we can about everyone, so we can be sure we know who would be "of interest"? Cardinal Richelieu would be delighted.
Now, if understand the typical Slashdotter's perspective, the government shouldn't be allowed to gather information on people of "no security interest", but they can't know who that is without gathering information. Naturally, then, we will lobby to prohibit all gathering of information, and when successful, we will mock the government's eventual failure to find people who are of "security interest" with their then-nonexistent capabilities.
Why, yes, most of us on Slashdot use a silly fake paradox to conclude that no investigative effort should ever gather any information. Idiot.
The real question is are you a troll or do you just come from a black and white world?
VOIP and other time-sensitive packets must be prioritized over other packets or performance of those services won't be acceptable to users.
ISPs want to argue that, but it's not as relevant as it looks. Because QOS priorities really only matter if the network is congested. And, the ISP shouldn't have congested backbone links.
The car analogies the ISPs offer up are broken. It's not really about being able to have a faster than *normal* lane. Having a higher QOS priority is more like driving in a normal speed toll lane during rush hour because the the non-toll lanes are congested. But, outside of rush hour, when the non-toll lanes are running just as fast, there's no point to paying to drive in the toll lane. ISPs shouldn't have the congested links that are analogous to the rush hour though.
Much of the ISP's desire to do shaping seems to be about having intentionally under-provisioned links and then either charging a toll to "uncongest" or making a competitor's traffic suffer while the ISP's traffic doesn't.
Abortions are not a right, never were: have been illegal for the past more than 100 years, ...
I'm sure you have some lame pseudo-legal argument that you think proves that statement, but you're wrong. Whatever your argument is, it's not something people are actually prosecuted under. Some abortions are legal. If they weren't, all the abortion clinics would have been closed down. The people that want to use the legal system to stop abortions are finding other ways. They do things like passing the recent Texas law that required that abortions only be done in facilities that have more surgical capabilities than is required for other more complex surgical procedures.
No, almost all the posters have it wrong - a carefully done re-implementation can be legit. You can't use the exact same potentially trade-marked names. You can't re-distribute the original art work. But, you can do things like create a new engine and anyone who owns the original game can then re-use the content in the new engine. See the article on Game Engine Recreation or the OpenMW project that's creating a version of the Elder Scrolls III: Morrowind game in a new engine.
That said, I don't know if this Metal Gear Solid remake wasn't careful to follow the rules or if maybe they did, but Konami gave them enough grief to make them stop anyway.
MS-DOS was more or less a CP/M clone. Unless I misremember, the first version didn't even have folders.
Don't forget that DOS started out as a Unix flavor...
Wow. You know, I had completely forgotten that. Please post more of this interesting history.
This is asinine. ... undercover agent, or something along those lines, leaking that information could make those people or their families vulnerable to kidnapping and violence.
How the hell is that +5 Insightful?!? I seriously doubt undercover FBI agents are using their real names! The only time their real name should come out is sometimes at trial.
Just because you have unauthorized access to do something and you have the skills to do so, that doesn't make it right.
Agreed...
[ Depending on a service offering (especially a dirt cheap one) is a risk ]
Which is why you should use layers of abstraction.
In this example, it would be sensible to support at least two services for back-end data storage. If you want a minimal footprint, you don't even have to ship your mobile app with multiple back-ends enabled (nor the config options to choose a back-end). You'd still be in a position to more quickly provide an update if the service disappears or looks like it's about to.
[...] you also have to create low-cost reusable rockets designed for repeat operation on the moon with little to no maintenance, fueled by materials from the lunar surface. Which is a vastly harder, more expensive task. After all, it makes no financial sense to mine a tonne of water from the surface of the moon and then deliver it into lunar orbit or beyond with 10 tonnes of hardware/propellant sent from Earth, which in turn took 100 tonnes to get off the surface of the Earth. Everything has to be long-term operable entirely in the lunar environment with lunar resources.
There's not any realistic budgeting scenario where it's even remotely cheaper, all capital costs included, to get your water from the moon in the remotely near future than to just launch it from the earth on existing rockets.
Electromagnetic mass drivers might make more sense than rockets for launching raw materials from the moon. At least that was what Gerard K. O'Neill and company concluded decades ago... Of course, you still have to build the mass driver on-site or deliver it there and run a mining operation.
I have to think that for sufficiently large scale offworld operations, you're going to want to mine materials from somewhere - either the moon or asteroids. As interesting as the topic is, I don't think we'll be building semi-permanent moon bases, Babylon 5, or mars colonies within ten years though.
INCONCEIVABLE!!!
I can't conceive of a man enjoying a chick flick though.
You keep using that word. I do not think it means what you think it means.
[ ... ] It's completely normal for a *nix based system to expose something like UEFI variables through the filesystem. It's a concept called Everything is a File and is the same reason why root can read and poke places in /proc and /dev to get information about the system or make changes to it.
Sure. But is the mapping provided here sane? It makes sense to provide a view of the variables as files. Reading the file should return that variables value. Writing the file should change that variables value. OK, so far.
If deleting the file is to have any effect on the actual UEFI variables, it should mean deleting the variable, not zeroing it. Does deleting UEFI variables from the BIOS even make sense? Note that for /dev, the files represent read/write/ioctl access to a device but that deleting a /dev file is like deleting a pointer to an object - it removes your pointer but has no effect on the object itself (and any other similar pointers are still usable). I strongly suspect that the filesystem for these variables should work the same way. Even if creating entirely new variables and deleting them from UEFI is a valid thing to do, it probably needs to be done by a mechanism other than filesystem semantics.
C and C++ are only the foundation because the happened to become popular due to a bunch of misc. factors, not because they are inherently great inventions in themselves. [ ... ]
No, C *was* a great invention. That there are other choices today doesn't change that. It was perhaps the first HLL (high level language) that was small, efficient, and yet also usable for low-level tasks. It was "small" in the sense that that it provided a minimal number of constructs and didn't provide any hard to parse features (unlike, for example, Ada). The fact that it was small was probably a big factor in C having one of the very first machine independent compilers, the Portable C Compiler.
From the Wikipeda C entry:
C is a general-purpose, imperative computer programming language, supporting structured programming, lexical variable scope and recursion, while a static type system prevents many unintended operations. By design, C provides constructs that map efficiently to typical machine instructions, and therefore it has found lasting use in applications that had formerly been coded in assembly language, including operating systems, as well as various application software for computers ranging from supercomputers to embedded systems.
[ Vendors ] are designing security into newer protocols...
That's nice... *today*. Well, assuming every protocol someone designs and that someone implements will be free of security flaws... But, "nice today" is not very useful long term.
Imagine, for example, that something is running using Windows XP or a decades old Linux distro. They could have had the best available security when they were built, but they would suck now. A decades old SSH would now be vulnerable.
It seems that historically, sites always end up with some sort of old cruft in existence. As long as you have to account for equipment not being patched or upgraded, the quality of that equipment's security is insufficient. You need layers. Sane physical controls. An architecture of least privilege. You probably want some sort of VPN that has a guarantee of ongoing security maintenance even when everything else doesn't. Even then, the network access should have some of the attributes you'd use in physical controls - you don't let Joe Whoever into just any control room, so *try* to not allow network connection from just anywhere.
Of the above layers, the architecture may be the most important. For example, if it's OK to be air-gapped, that takes a lot of attack vectors off the table.
HTTPS is the only real answer. Rules like what are being proposed are hard to enforce. But properly implemented authentication and encryption will make such rules unnecessary.
Nope.
HTTPS is necessary, but woefully insufficient for protecting your privacy. Even with everything encrypted, your ISP still knows what sites you connect to - they do route the packets, after all.
Would it be OK if which ads are displayed on your TV to be affected by which sites you visit? And "you", of course, includes anyone in your household and your WiFi guests. Which snail mail adverts are sent to your billing address or service address? Or, in general, whether or not your name appears on various targeted advertising lists? Or lists that aren't at all about advertising...
A VPN will prevent your ISP from doing this, but then gives your VPN host the same capabilities.
On a similar note, we've had a bunch of articles here about how it's almost impossible to prevent web browser fingerprinting from allowing you to tracked from one web site to another. But, your ISP is in a special position to know all that you visit and who/where "you" are.
Here's the letter that was sent.
A different FA has some comments and/or speculation on how some ISPs are (ab)using customer info.
... Now you're telling me a company called Internatioal "Business" Machines had some sort of weird 32 bit computer family in the 1960s?
I didn't read TFA, but I'm guessing the 360 was one of the first or second generation of 32-bit machines. Decades ago 32-bit wasn't the thing. A lot of the bigger older machines used 36 bit data types. That allowed integers up to 10 decimal digits long to be represented so that these new electronic computers could compete with the 10 digit mechanical computers that preceded them. Later, the advantages of using powers of two won out over that compatibility.
I skimmed an article about the pinch now hitting higher priority water rights holders while waiting at a doctor's office yesterday. Apparently people and corporations have water rights going back over a hundred years that control who does and does not get water. They still have to pay for it though. Seems like the legalized prioritizations might make a lot of the discussion about what water should and should not be used for moot. Or, as usual, that simplistic solutions aren't feasible.
So, it's exactly like he said and no updates are allowed to be installed.
ISVs are shit at security because nothing about security is their problem. Being in healthcare doesn't change that; if anything, it makes it worse. I would expect a vendor to spend exactly zero effort on verifying security updates, and less than that on notifying customers. If it ain't a new sale, they ain't interested.
Honestly, I hope some hospital gets the balls to sue an ISV for failing to act in a timely manner for perpetually ignoring security like we all know they do. It's not going to change until someone holds them accountable. They'll just hide behind their EULAs until then, and hospitals will get the bill for letting people die because of security holes.
From the linked FDA page:
4. Who is responsible for ensuring the safety and effectiveness of medical devices that incorporate OTS software?
You (the device manufacturer who uses OTS software in your medical device) bear the responsibility for the continued safe and effective performance of the medical device, including the performance of OTS software that is part of the device.1
If the device manufacturers are forcing hospitals to run without OS patches, the manufacturers are not doing what the FDA says they should do. Maybe the FDA should change should to required. Even so, I have to wonder if there's anything preventing the manufacturers from simply maintaining a patch compatibility web page and telling the hospitals that they're responsible for the OS patches... I seriously doubt either party is innocent, but have to wonder if the hospitals are the bigger culprit.
Posting to undo moderation mistake.
... not just with AND and OR, but also "within so many words"...
Try Google's firstterm AROUND(3) secondterm.
"I'm going to work for the IRS" said no competent, industrious individual. Ever.
Work for? Yes. Stay? No.
An IRS auditor once told me that IRS experience looks great on a resume if you want to work as a tax accountant or similar. He said the job at the IRS wasn't great, but that the experience was valuable. So, he continued, the IRS has lots of turnover.
I've had returns questioned a few times. The above conversation occured when I was working as contracter and the IRS claimed we'd underpaid taxes after they recorded my quarterly estimated taxes to my SSN in their databases and our recorded our *joint* April 15th taxes to my wife's SSN. It took a couple of years to settle IIRC, and it seemed there was a different agent every few months.
This!
[ A summary of a discussion from http://www.sitepoint.com/open-source-licensing/ and lots of good links re licensing issues. ]
The parent easily spent an hour or few putting that together.
Another good resource is one of the chapters of http://producingoss.com/
I published a project on github a year or couple ago. It is/was in an alpha state and not functional, so there's no huge interest. Figuring out what license to use took some time because of interactions with other efforts. My project makes use of files licensed under the MIT license. I expect to eventually contribute my code to another project that uses what seems to be an ISC license. I need the user to download a library that's only available as source. Not the most complex situation, but researching the license options takes time.
I can imagine that some people want to publish their code, but are either unaware that the default license is "all rights reserved", don't care, or care but don't want to spend the time to figure out what's appropriate.
The default license is "all rights reserved". When you create a new (public) project, github should require you to acknowlege that or to specify a license. A link to a good discussion of licensing issues could be included. The list of licenses to choose from should include "all rights reserved" and "see project-specific license". I'm not sure that "public domain" should be on the list because IIRC you need at least a minimal license to say "no warrenty" and provide a "limitation of liability". Project owners could still leave their code unlicensed.
Seems like a bit of FUD on both sides of the argument...
A while back, I spent a few minutes skimming the Wayland FAQ and Wayland Architecture Diagram. Interesting stuff, especially the architecture page, and they provide actual detail while the TFA mostly doesn't.
For comparison of the two architectures, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that Wayland *is* a compositor that provides both window manager functions and some of the functionality of an X server.
From what I can see, here's the architectual differences between X and Wayland when it comes to supporting remote app display:
Intentionally misstating by being over simplistic, 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 than an X server would 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, both the TFA and the FAQ report this and note that you'll need X server(s) in addition to Wayland for the foreseeable future. The X server(s) talk to Wayland instead of to hardware.
There's going to be support for running Wayland apps remotely. 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 have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient...
The discussion of doing remote Wayland apps seems to revolve around how to transmit the per-app buffers across the network instead of handing the buffer to the local Wayland compositor / display driver. Or perhaps about having the compositor know that certain app buffers should be transmitted instead of composited to the local display, but that's almost the same thing when viewed as a flow.
Transmitting bitmap deltas works pretty well, but for some apps, sending higher level information such as the original OpenGL might be better. With X, they defined an extension, GLX for essentially passing the OpenGL to a remote server. Similarly, I imagine it would be useful if an OpenGL app could talk to a remote Wayland server instead of sending bitmap deltas. So, it looks to me like it would be useful to define an extension mechanism for transport that would allow OpenGL commands to be sent to a remote computer where they could be rendered to a remote buffer and handed off to the remote Wayland compositor. Bonus points if the extension mechanism is generic. Seems like transport of audio might be another fit for a modern replacement of X.
Not an X server developer nor a Wayland developer. I may have garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the
No, the key has to be inside the passenger compartment to start it.
My sister reports that her car started just fine with the keys on the roof or hood. Not that they stayed there after the car started moving...
You already (should) be buckling a seat/shoulder belt. That's more effort than putting a key in a key hole. So, I don't see that the risks of keyless entry *and* starting make up for the minor convenience of not having to use a key. YMMV.