Hello USA , Hello UK, Hello any of the usual suspects.
Hello any country with resources that wants to make one of the above countries look bad by framing them and
then "discovering" new malware in the wild.
I'm only half-kidding. over the past year or two, there's been a nifty cottage industry of small storefronts that perform screen replacements on cell phones. If that number gets cut in half, things are going to get interesting for these store owners.
Firstly; I think the old phones will still be widely used for a few more years, as long as the price of a screen replacement is low comparable to the cost of a new phone, I think they will be okay for at least another year, they were always a market of limited duration meeting a temporary need.
Otterbox and other impact resistant cases. Not only would this impact Otter Products, but also many retailers, since cases tend to be a high-margin upsell, so their profits would slip.
I suspect their margin may need to become thinner, but this is less likely. It's easy to see how fewer broken screens will affect sales of screen replacement service, however, the sales of impact-resistant cases are going to be primarily linked to customer perception of risk. The new screens don't make the phone waterproof, and then there are is that iPhone 6+ bending issue, which may very well have increased sales of cases.
Next, people view their cases or phone skins as a fashion statement, and I don't see that going away .
Finally, there are people who buy the cases because they need or want a blackberry-style holster, and again, even with impact-resistant glass, the concern of damage to the phone, scratching, or wear from routine daily use remains, and there will be many people who won't perceive the improved glass as a subsitute for a ogod case.
It depends on whether you consider the gorilla glass version previously used by iPhones as a competitor or not.
Generally the reading "competitive cover glass now in the market" would be a comparison against only glass made
by OTHER COMPANIES', not previous versions of your own product which are now deprecated.
It is all in the design and implementation. Binary formats and protocols generally have field and record delimiters, as well as error detection and correcting features like checksums.
In my experience, bespoke file formats do not have any of these things, or they are not reliable at all.
Of course Mission-critical filesystems such as Ext4, and Enterprise-application DBMs such as PostgreSQL, Oracle, or even MySQL (as long as you use InnoDB and not MyISAM) have many hundreds of thousands of man-hours in developing their binary file formats and tools to help repair them.
But systemd is new. The new logging format has none of that level of engineering and effort behind it, therefore; there is absolutely no reason to believe that systemd's journal is meeting a level of real-world production-usable robustness comparable to the Ext filesystem or comparable to PostgreSQL, which have been used by hundreds of thousands of large enterprises over 15 years of production experience.
There is no "mostly ACID"--a database is or isn't, and the human-readability of a file has no bearing on how corruptable it is. Things like underlying file system and implementation have more to do with it.
Incorrect. Corruption can occur on both binary and human-readable files. The impact of corruption on a binary file is much more severe. The corruption of a human-readable file can generally be resolved by humans. Humans can't read the binary file in the first place, and in general, the computer can't resolve the binary file corruption, and generally, the only way it can be resolved is for the programmer who designed the proprietary binary file format to analyze the file, or for specialized tools such as E2fsck to be developed which discard rather than attempting to recover bits from apparently corrupted data.
The point is the term "ACID" is not really applicable to a text-based log in the first place; it's an inappropriate use of the term. ACID refers to a standard of transactional integrity of a relational database.
Text-base syslog files never update a previous entry, and every record only has one column, so it DOESNT MAKE SENSE to speak of the relational integrity of a text syslog file.
You could say the text logfile is fully ACID compliant, except, in some cases, the Log rotation operation is often not ACID compliant, since it may be performed by a script without the proper care.
Failed transactions roll back cleanly and single byte errors most certainly do NOT render all data theteafter inaccessible! Despite that you have binary formatted data, even if it is all VARCHAR fields.
In my experience... PostgreSQL will shutdown and refuse to start back up.
You will then be in for a lengthy restore from backup followed by point in time recovery efforts by replaying transaction logs, or a very lengthy repair process. MySQL has similar issues.
I'm not saying this is bad for pgSQL or MySQL, as there are definitely efficiency requirements that drive the design, but the fact is that they cannot cope with corruption so well; they can do fairly well with some common problems, such as a pull of the plug, that is: assuming the SYNC command really does guarantee written data is committed to stable media before returning execution.
Apply what ever laws for DSL to have dry loop DSL to Coax so that you have dry loop COAX.
The problem with this idea is that a Dry Loop is an actual thing; it's a physical connection, and it's a good match for the technology. Your dry loop is a dedicated electrical circuit.
A cable distribution network works differently. There is no dedicated circuit from the cable company to each customer; everything connects back to a headend..
And it's a ginormous broadcast network.
There's no cable running back to the cable company labelled "John Doe's line"
Customers don't have dedicated wiring back to the headend, therefore; it is impossible to create a dedicated electrical circuit.
Furthermore..... spectrum on the cable lines are limited and have to be shared with video.
The cable company has to choose how they want to carve up their spectrum and ultimately which frequency ranges their headend will allow for broadband channels.
Finally, all the bandwidth on the headend is shared among customers in a neighborhood or general area, and this is one of the bottlenecks that prevents "unlimited" service.
It's essentially as if there is an Ethernet network with all customers plugged into the same switch, and some additional security measures on the endpoint devices to prevent sniffing.
However, it's kind of like an old style thicknet, in that there is not a dedicated homerun for each customer back to the central point.
It is inherently shared; every device transmitting inherently consumes the cable company's property, so there's really no room for a true "Dry Loop".
Well; providing just one of the services may be more complicated, as they need to install additional hardware to block the TV services they aren't providing, but possibly that will create additional costs when they want to move towards an all digital network and reclaim TV frequencies to be used for service A.
In other words.... blocking Service B and maintaining the block creates additional costs
The fines that UNSW are levying are for breaches in the terms (or rules) by which students access the institution's network services.
However, in this case, it means that the university is benefitting from the copyright infringement being conducted on their network, since they are collecting a 'fine', or a 'fee'.
I don't know about NSW, but in other jurisdictions if you knowingly profit from the infringement (charging a fee to the infringer), and you facilitate the infringement (by providing the computer network), then you become liable for the infringement as well, or you may be a contributory infringer. It's no different from others such as Mega being held to answer from infringement on their public website since they receive Ad money.
Is this really a loophole? What happens if I go to amazon.com and find one of these $100 playstations, and quickly buy it, then insist they honor the contract?
Should they fail.... bring it to court, suing them for the difference between the price agreed and the best available offer. Subpoena walmart for records of the price match as proof that the $100 listing for sale was known and intended.
A moat is excessively expensive, really unnecessary, an eyesore, and is still not going to really stop or hinder a marine who is determined.
Furthermore, the White House is supposed to be a place where people from the public can indeed come; it's not supposed to be a castle or an ivory tower.
It should only be fort knox during those times when the president is home.
As for ensuring the president's security; I suggest an additional wider perimeter with a triple-layer fence, with all vehicles and persons required to be searched/checked for weapons etc, and restrict access to all nearby buildings as well.
There should be multiple 24x7 "spotters" high up when the president is in the vicinity, and video analytics, scoping the entire grounds outside for potential intruders and sounding an alarm.
There should be additional locks on the doors and teargas traps which can be activated remotely during an attempted breakin.
Apparently any Debian developer can now chose to make their package only work with Systemd
I'm working on submitting patches to Vi, Emacs, Bash, Dash, Tcsh, Zsh, Ksh, Ash, and Sh to add systemd as a dependency.
They'll also have a simple line of code to check if the systemd binary is present, and if it's missing, not running as PID #1, or
doesn't pass some rudimentary fingerprint tests, exit silently.
One curious corollary is that if the human brain is a Turing machine, then humans can never decide this issue either, a point that the authors deliberately steer well clear of.
Instead of considering an 'Evil Programmer'..... consider 'Evil Judge', 'Evil Military General', 'Nazi', or 'Evil Dictator'
And instead of just deciding this issue; add the problem of surviving this issue together with the problem of deciding how to maximize your chances at survival and happiness in concert with previous issue.
As I understand it they introduced changes independent of the security fix, and the
non-fix-related feature additions caused the problem.
They shouldn't have rolled new features in the same patch, BUT if they did, they should have included
common software used by more than 10% of windows systems in their test cases and basic functionality such as HTTPS compatibility.
There has already been one major compatibility bug in the patch for MS14-066 released November 11, where you update your IIS server to fix the SSL remote code exec bug, and Chrome browsers stop working..
Furthermore, there were several botched updates in October.
Windows 7 blue screens with a patch in September
I don't know what the deal is, but it looks like maybe Microsoft stopped testing security patches on August's patch tuesday, or something.
As if the pro-systemd side was the only one with activist fans who don't understand the actual situation.
Oy... you still don't get it. For some reason those favoring systemd have been given a pass.
I guess it is because a few distros have used it and people who support systemd who are not listening far outnumber those who have opposed systemd and stated logical reasons or noted issues.
As a result, the burden of proof rests on anyone opposing the introduction of systemd.
Because the burden of proof rests on those opposing the introduction of systemd; it doesn't even matter if some are fanatical, because it has zero net affect.
The problem is the rational arguments showing that the status quo is better than systemd are just getting ignored and not being addressed.
ACID and that it'll be easily corrupted in a crash but never quite manage to explain how the plain text log doesn't have the same problem.
Plain text logs have risk of corruption as well, but unlike text-based logs, binary logs are fragile.
I would say it's true that the same can happen to both --- they both have risks of corruption, BUT the binary logs are much more likely to have debilitating corruption.
One byte out of place, and the entire file tends to become unusable, or systems that need to consume the logs break and can't read the rest of the logfile.
When a text-based log has a corruption issue; generally, it will mean a few lost log entries -- the write operations are fairly atomic. It doesn't matter that they aren't transactional, because text-based log storage is not as fragile as a binary file format that must be well-formed, or your log-reading tool goes KaBoomb.
With regards to logs; it only makes sense to refer to ACID compliance, when there is a relational transaction structure that must be preserved to recover the log entry. Generally with a text-based logfile, EVERYTHING that is relevant to the log entry goes to a single log line and gets written all at once, so this is really robust and hard to beat.
You wasted your money. Apple themselves simply eliminate the temperature sensor when an SSD is installed, as they run cool no matter what.
I didn't see it that way; it was a $15 piece anyways.. it would have been extra work to cut up the temperature sensor wires, splice and cap them, and this would ruin the reversibility of my change, in case I need to go back and claim warranty. If I had bought the Apple part instead of using my own, it would be an additional $400 or $500 for a 260gb SSD.
So many people don't understand, the whole point of Open/Free software is that you can fork the source if somebody takes it in a direction you do not like, you don't pay for it and you do not get to dictate what the authors do with it but you are free to make it your own if you choose to.
In this case, you are suggesting they should have to fork all of Debian, because that's the only way to keep something other than systemd once Debian switches. Every package in the system has to be compatible with the init system.
Also, why don't you just fork Debian if you want to have Debian with SystemD.
What makes you say that it's those who want to keep the status quo who should have to fork?
This is not the way Debian works; it is a collaborative project, and it doesn't work unless everyone cooperates and adheres
to the policies.
The argument to not use X in Debian would have as much potential merits as any argument to use X in Debian.
The cost of forking is insane, and it's not really a viable way forward
Exactly. Using ridiculous namecalling for folks challenging systemd such as "immature twats" is taking sides.
It's not possible to have a reasonable collaboration so long as systemd has activist fans who do not take the time and care
to understand the criticisms.
I've done it on certain iMac moddles without any additional software by purchasing an additional temperature sensor and plugging that in instead of plugging the Hard Drive temperator sensor into the 3rd party SSD. ^_^
School under Education License agreements pay about $34/year per desktop for the current OS
$34 is not a lot, but for 3000 desktops, it is still not zero.
If you can use a cloud based MDM solution or open source based management tools, then
your $100,000 CAL budget becomes a $5,000 annual cloud or on-premise MDM server license.
Slashdot Mirror
Hello USA , Hello UK, Hello any of the usual suspects.
Hello any country with resources that wants to make one of the above countries look bad by framing them and then "discovering" new malware in the wild.
This is what their reaction used to be when we talked about switching Windows servers' operating system to Linux. "Linux? No! Wtf is Linux?"
I'm only half-kidding. over the past year or two, there's been a nifty cottage industry of small storefronts that perform screen replacements on cell phones. If that number gets cut in half, things are going to get interesting for these store owners.
Firstly; I think the old phones will still be widely used for a few more years, as long as the price of a screen replacement is low comparable to the cost of a new phone, I think they will be okay for at least another year, they were always a market of limited duration meeting a temporary need.
Otterbox and other impact resistant cases. Not only would this impact Otter Products, but also many retailers, since cases tend to be a high-margin upsell, so their profits would slip.
I suspect their margin may need to become thinner, but this is less likely. It's easy to see how fewer broken screens will affect sales of screen replacement service, however, the sales of impact-resistant cases are going to be primarily linked to customer perception of risk. The new screens don't make the phone waterproof, and then there are is that iPhone 6+ bending issue, which may very well have increased sales of cases.
Next, people view their cases or phone skins as a fashion statement, and I don't see that going away .
Finally, there are people who buy the cases because they need or want a blackberry-style holster, and again, even with impact-resistant glass, the concern of damage to the phone, scratching, or wear from routine daily use remains, and there will be many people who won't perceive the improved glass as a subsitute for a ogod case.
Watered down diamonds or Carbon nanotubes? :)
It depends on whether you consider the gorilla glass version previously used by iPhones as a competitor or not. Generally the reading "competitive cover glass now in the market" would be a comparison against only glass made by OTHER COMPANIES', not previous versions of your own product which are now deprecated.
It is all in the design and implementation. Binary formats and protocols generally have field and record delimiters, as well as error detection and correcting features like checksums.
In my experience, bespoke file formats do not have any of these things, or they are not reliable at all. Of course Mission-critical filesystems such as Ext4, and Enterprise-application DBMs such as PostgreSQL, Oracle, or even MySQL (as long as you use InnoDB and not MyISAM) have many hundreds of thousands of man-hours in developing their binary file formats and tools to help repair them.
But systemd is new. The new logging format has none of that level of engineering and effort behind it, therefore; there is absolutely no reason to believe that systemd's journal is meeting a level of real-world production-usable robustness comparable to the Ext filesystem or comparable to PostgreSQL, which have been used by hundreds of thousands of large enterprises over 15 years of production experience.
There is no "mostly ACID"--a database is or isn't, and the human-readability of a file has no bearing on how corruptable it is. Things like underlying file system and implementation have more to do with it.
Incorrect. Corruption can occur on both binary and human-readable files. The impact of corruption on a binary file is much more severe. The corruption of a human-readable file can generally be resolved by humans. Humans can't read the binary file in the first place, and in general, the computer can't resolve the binary file corruption, and generally, the only way it can be resolved is for the programmer who designed the proprietary binary file format to analyze the file, or for specialized tools such as E2fsck to be developed which discard rather than attempting to recover bits from apparently corrupted data.
The point is the term "ACID" is not really applicable to a text-based log in the first place; it's an inappropriate use of the term. ACID refers to a standard of transactional integrity of a relational database. Text-base syslog files never update a previous entry, and every record only has one column, so it DOESNT MAKE SENSE to speak of the relational integrity of a text syslog file. You could say the text logfile is fully ACID compliant, except, in some cases, the Log rotation operation is often not ACID compliant, since it may be performed by a script without the proper care.
Failed transactions roll back cleanly and single byte errors most certainly do NOT render all data theteafter inaccessible! Despite that you have binary formatted data, even if it is all VARCHAR fields.
In my experience... PostgreSQL will shutdown and refuse to start back up. You will then be in for a lengthy restore from backup followed by point in time recovery efforts by replaying transaction logs, or a very lengthy repair process. MySQL has similar issues.
I'm not saying this is bad for pgSQL or MySQL, as there are definitely efficiency requirements that drive the design, but the fact is that they cannot cope with corruption so well; they can do fairly well with some common problems, such as a pull of the plug, that is: assuming the SYNC command really does guarantee written data is committed to stable media before returning execution.
It left China with either letting go of censorship, or breaking significant chunks of the Internet for their population.
DMCA-style takedown or GEO-Lockdown of CDN content upon an e-mail request of the Chinese government.
Apply what ever laws for DSL to have dry loop DSL to Coax so that you have dry loop COAX.
The problem with this idea is that a Dry Loop is an actual thing; it's a physical connection, and it's a good match for the technology. Your dry loop is a dedicated electrical circuit.
A cable distribution network works differently. There is no dedicated circuit from the cable company to each customer; everything connects back to a headend..
And it's a ginormous broadcast network.
There's no cable running back to the cable company labelled "John Doe's line"
Customers don't have dedicated wiring back to the headend, therefore; it is impossible to create a dedicated electrical circuit.
Furthermore..... spectrum on the cable lines are limited and have to be shared with video. The cable company has to choose how they want to carve up their spectrum and ultimately which frequency ranges their headend will allow for broadband channels.
Finally, all the bandwidth on the headend is shared among customers in a neighborhood or general area, and this is one of the bottlenecks that prevents "unlimited" service.
It's essentially as if there is an Ethernet network with all customers plugged into the same switch, and some additional security measures on the endpoint devices to prevent sniffing.
However, it's kind of like an old style thicknet, in that there is not a dedicated homerun for each customer back to the central point.
It is inherently shared; every device transmitting inherently consumes the cable company's property, so there's really no room for a true "Dry Loop".
Well; providing just one of the services may be more complicated, as they need to install additional hardware to block the TV services they aren't providing, but possibly that will create additional costs when they want to move towards an all digital network and reclaim TV frequencies to be used for service A.
In other words.... blocking Service B and maintaining the block creates additional costs
The fines that UNSW are levying are for breaches in the terms (or rules) by which students access the institution's network services.
However, in this case, it means that the university is benefitting from the copyright infringement being conducted on their network, since they are collecting a 'fine', or a 'fee'.
I don't know about NSW, but in other jurisdictions if you knowingly profit from the infringement (charging a fee to the infringer), and you facilitate the infringement (by providing the computer network), then you become liable for the infringement as well, or you may be a contributory infringer.
It's no different from others such as Mega being held to answer from infringement on their public website since they receive Ad money.
Is this really a loophole? What happens if I go to amazon.com and find one of these $100 playstations, and quickly buy it, then insist they honor the contract?
Should they fail.... bring it to court, suing them for the difference between the price agreed and the best available offer. Subpoena walmart for records of the price match as proof that the $100 listing for sale was known and intended.
A moat is excessively expensive, really unnecessary, an eyesore, and is still not going to really stop or hinder a marine who is determined. Furthermore, the White House is supposed to be a place where people from the public can indeed come; it's not supposed to be a castle or an ivory tower. It should only be fort knox during those times when the president is home.
As for ensuring the president's security; I suggest an additional wider perimeter with a triple-layer fence, with all vehicles and persons required to be searched/checked for weapons etc, and restrict access to all nearby buildings as well.
There should be multiple 24x7 "spotters" high up when the president is in the vicinity, and video analytics, scoping the entire grounds outside for potential intruders and sounding an alarm.
There should be additional locks on the doors and teargas traps which can be activated remotely during an attempted breakin.
Apparently any Debian developer can now chose to make their package only work with Systemd
I'm working on submitting patches to Vi, Emacs, Bash, Dash, Tcsh, Zsh, Ksh, Ash, and Sh to add systemd as a dependency.
They'll also have a simple line of code to check if the systemd binary is present, and if it's missing, not running as PID #1, or doesn't pass some rudimentary fingerprint tests, exit silently.
(By the way, I'm just kidding)
I'm good with coders in congress; as long as they have debugging experience, and most of the bugs were in code written by their peers.
One curious corollary is that if the human brain is a Turing machine, then humans can never decide this issue either, a point that the authors deliberately steer well clear of.
Instead of considering an 'Evil Programmer'..... consider 'Evil Judge', 'Evil Military General', 'Nazi', or 'Evil Dictator'
And instead of just deciding this issue; add the problem of surviving this issue together with the problem of deciding how to maximize your chances at survival and happiness in concert with previous issue.
As I understand it they introduced changes independent of the security fix, and the non-fix-related feature additions caused the problem.
They shouldn't have rolled new features in the same patch, BUT if they did, they should have included common software used by more than 10% of windows systems in their test cases and basic functionality such as HTTPS compatibility.
There has already been one major compatibility bug in the patch for MS14-066 released November 11, where you update your IIS server to fix the SSL remote code exec bug, and Chrome browsers stop working..
Furthermore, there were several botched updates in October.
Windows 7 blue screens with a patch in September
I don't know what the deal is, but it looks like maybe Microsoft stopped testing security patches on August's patch tuesday, or something.
Except you need to be a licensed telco with permits to access those utility easements.
As if the pro-systemd side was the only one with activist fans who don't understand the actual situation.
Oy... you still don't get it. For some reason those favoring systemd have been given a pass. I guess it is because a few distros have used it and people who support systemd who are not listening far outnumber those who have opposed systemd and stated logical reasons or noted issues. As a result, the burden of proof rests on anyone opposing the introduction of systemd.
Because the burden of proof rests on those opposing the introduction of systemd; it doesn't even matter if some are fanatical, because it has zero net affect.
The problem is the rational arguments showing that the status quo is better than systemd are just getting ignored and not being addressed.
ACID and that it'll be easily corrupted in a crash but never quite manage to explain how the plain text log doesn't have the same problem.
Plain text logs have risk of corruption as well, but unlike text-based logs, binary logs are fragile.
I would say it's true that the same can happen to both --- they both have risks of corruption, BUT the binary logs are much more likely to have debilitating corruption.
One byte out of place, and the entire file tends to become unusable, or systems that need to consume the logs break and can't read the rest of the logfile.
When a text-based log has a corruption issue; generally, it will mean a few lost log entries -- the write operations are fairly atomic. It doesn't matter that they aren't transactional, because text-based log storage is not as fragile as a binary file format that must be well-formed, or your log-reading tool goes KaBoomb.
With regards to logs; it only makes sense to refer to ACID compliance, when there is a relational transaction structure that must be preserved to recover the log entry. Generally with a text-based logfile, EVERYTHING that is relevant to the log entry goes to a single log line and gets written all at once, so this is really robust and hard to beat.
You wasted your money. Apple themselves simply eliminate the temperature sensor when an SSD is installed, as they run cool no matter what.
I didn't see it that way; it was a $15 piece anyways.. it would have been extra work to cut up the temperature sensor wires, splice and cap them, and this would ruin the reversibility of my change, in case I need to go back and claim warranty. If I had bought the Apple part instead of using my own, it would be an additional $400 or $500 for a 260gb SSD.
So many people don't understand, the whole point of Open/Free software is that you can fork the source if somebody takes it in a direction you do not like, you don't pay for it and you do not get to dictate what the authors do with it but you are free to make it your own if you choose to.
In this case, you are suggesting they should have to fork all of Debian, because that's the only way to keep something other than systemd once Debian switches. Every package in the system has to be compatible with the init system.
Also, why don't you just fork Debian if you want to have Debian with SystemD.
What makes you say that it's those who want to keep the status quo who should have to fork?
This is not the way Debian works; it is a collaborative project, and it doesn't work unless everyone cooperates and adheres to the policies.
The argument to not use X in Debian would have as much potential merits as any argument to use X in Debian.
The cost of forking is insane, and it's not really a viable way forward
Exactly. Using ridiculous namecalling for folks challenging systemd such as "immature twats" is taking sides. It's not possible to have a reasonable collaboration so long as systemd has activist fans who do not take the time and care to understand the criticisms.
I've done it on certain iMac moddles without any additional software by purchasing an additional temperature sensor and plugging that in instead of plugging the Hard Drive temperator sensor into the 3rd party SSD. ^_^
Some cities have quite nice and convenient public transit, and it can be even better if you live and work in the right places.
Yes, and they're all outside the United States. :-)
School under Education License agreements pay about $34/year per desktop for the current OS
$34 is not a lot, but for 3000 desktops, it is still not zero. If you can use a cloud based MDM solution or open source based management tools, then your $100,000 CAL budget becomes a $5,000 annual cloud or on-premise MDM server license.