And, in the chromebook, having the option to go to a GNU/Linux full distro for full flexibility and Application Support...
And go back to GOOGLE ChromeOS if you do not like the complexity of the command line, and the multitude of choices for UI/WindowManager/InitSystem/Systemd/PulseAudio/ALSA...
And the security implications of downloading applications from anywhere not vetted in the store...
Think Grandma, or a technicaly inclined father that gets bored playing with the "Linux on chromebook" and decides to give it as a hand me down to its infant child.
As per data colection: What part of GOOGLE ChromeOS was not clear?
I can not vouch for the German part, but the Spanish dictionaries in Open/LibreOffice can not hold a Candle to their MSOffice Counterparts.
If the Spelling, Grammar and thesaurus dictionaries in LibreOffice in German are as bad as their counterparts in Spanish, then is office for the win...
The English ones are serviceable. And OpenOffice originating with a German company (a loooong while ago) may help a little bit there.
If you have old or underpowered hardware (as in only two threads, and lower than Core2 Duo), do not install this, and stick to 52-ESR. The penalty for the extra context switches will kill you.
If you are in a memory restricted machine, stick to 52 ESR, as the added overhead of four processes will eat memory away, more so in the 64 bit version.
If you depend on custom NPAPI plug-ins (other than flash), stick to 52ESR, as support for NPAPI (other than flash) is blocked in 53 and onwards.
If you are on XP, stick to 52ESR (this advice is redundant, as newer versions will refuse to intall on XP without some hacking).
If there are plugins that are essential to your workflow, consider either staying on 52 ESR, or do your due diligence, as this multiprocess breaks a lot of ad-ons.
Having said all that, I am happy that firefox is moving in this direction, which I think is the right one, and will bring massive benefits for the years to come in exchange for a little disconfort and inconvenience for a short while...
I am sad that I need to stay on 52ESR (as I need a lot of IPIMI plugins, sabameeting plugins, webex plugins, and lots of other crap to be effective at work).
Hope you enjoy betatesting this for us on the ESR channel, and polishing the rough edges.
Now more seriously, is because of sandboxing. A process is forbiden to read or write on the memory space of another process, meanwhile every thread indide a process can read/write in the memory space of it's sister's threads (i am a spanish speaker. hebra=thread is femenine for us)...
So, if you used threads instead of processes, thread handling tab from malicious website a, coud trivially snoop/hack/crash websites in tabs b,c,d,e....
With processes, this becomes much much harder...
But in the end, is because chrome has been doing it like that since inception, and Firechrome-er i mean, fox, firefox, imitates chrome
But I am an electornics engineer (but not in Utah).
If you recall, Microsoft and Qualcom are using emulation to run 32bit apps. Therefore IA-32.
IA-32 is firmly intel patented. These patents are licensed to AMD under a variety of agreements, on in particular in 2001. The other side of the coin is that Intel Licenses a big chunck of AMD's AMD-64 ISA, which is not emulated by Microsoft-Qualcom.
Therefore, any claim over the use of IA-32 has to be done by intel (AMD would be more than happy to license the AMD-64 ISA for the right amount of cash).
As stated by others, in the USoA, patents only last 17 years, but remember that over the last few years we have seen, MMX, SSE, SSE2, SSE3, AVX, AVX2, virtualization support, etc. Many of those instructions exist in 32 bit SW as well. And are still covered by patents by intel. Not emulating those leads to iffy app support under emulation, so your emulation has to work "around" the patents. OR, you go to court and try to invalidate them...
So, there is a strong possibility that intel has grounds for a claim. Whether they have *enough* ground, that's a differnt story...
Of course, Microsoft and Qualcom are no pushovers whatsoever, so, it would be nice to watch a fight between those three...
But do not just assume that Intel's threat is a tiger paper...
Even if machines or NASes are internal to the network, someone may send you a boobytrapped email or webpage, and infect the suceptible machines from INSIDE the network, sort of like one of the modes of contagion from the WCry worm
I've been following this with a lot of attention. (here is The Register's take on the matter, by the way: https://www.theregister.co.uk/... )
And I, as many other commenters, think that the real problem is not on linux servers or Workstations with supporrted distros, for which patches already exist, but rather, on many Abandoned Distros, many cheapo NAS boxes, home Routers, IoT stuff and other dohickeys that use Linux on their firmware behind the scenes. I've a synology DS1515+ in my lab at home, and the bug was squashed on may 25, but the fix has not yet propagated to my NAS via automatic updates, but at least there is a fix (and no, SMB is not open to the Internet).
Now, think of those cheapo NAS boxes that do not see a firmware update in years, or those routers with a USB port in the back to slap a USB HDD and "share files effortlessly", or Distros like one of my old time favourites Damn Small Linux. Those are likely So Out of Luck...
No, I do not think this will be a SaMBaPOCALIPE, but I will be bad for some people.
From the SUMARY: "The change will prevent clients from fully accessing some network computers and may disable some expected functions for connected Windows machines."
So, it seems that your connected Windows machines use the expected functions that the setting disables.
Go figure.
Good though to know one of the error messages that may arise after turning of the setting.
FOSS isn't a magic bullet, it's a development model. The advantages play out in statistical trends, and the differences in those trends can depend on many factors, including how 'open' development is. For example, WannaCry is somewhat comparable, and since it affected XP, the issue likely existed for at least 9 years, if not longer.
Submitter here:
I agree with you 100%. The point is that many people in the FOSS community think that the many eyes are indeed a magic bullet, and the only thing needed to weed out bugs, when, as you said, is not.
If you see my post history, you will see that my long standing oppinion is that many eyes are not enough. One needs ENOUGH Qualified AND Motivated eyes, as well as test cases and structured QA.
I came to that realization during the Metafile Fiasco of Dec. 2005.
We had two codebases, one Closed (windows) and One Open (wine). Neither was able to realize the security implications of the code. It took a third party (sysinternals IIRC) to realize the security implications. Even with many eyes, no one in the wine team realized the security implications of the metafile behaviour. At the time some people said "That's because the wine team were copying the behaviour of windows"
That is disingenuous, for if the wine team had realized the security implications, they would had bang on that drum like crazy, and made a config option of the form [metafile bug=0, 1, 2] 0=keep error for compatibility; 1=wineteam fix; 2= microsoftfix if and when released...
So, to sum up. Many eyes are nice to have, but not a panacea. For good code (less bugs, less security issues), one needs not MANY eyes but, ENOUGH QUALIFIED AND MOTIVATED EYES (of course, if you have many eyes, you MAY get ENOUGH of the eyes you need, but it is not guaranteed). Also, for good code one needs good test cases and a good QA process.
Assume no ISP respects your privacy, and act accordingly.
Maybe and ISP simply does not respect your privacy, but at least have the decency to tell you to your face, maybe the ISP "Says" it respects your privacy, but behind your back is monetizing your info, maybe they respect your privacy "Today", but are under intense financial/govermental pressure to not respect it in the future.
So, Once you decide that NO ISP is respecting your privacy (instead of asking on May 23, 2017 which ones do and which ones do not), you can act accordingly, and it does not matter anymore.
Use services that allow you to aggregate various ISPs (using MLPP) to both get a faster internet AND get the ISP of your scent, then use proxies and/or VPNs to cover your tracks, couple that with anonymizing browsers for an added level of protection. Put all the Browser crap in a RAMDISK for even more protection.
As a reader of Slashdot, you probably have the technical acumen to do it.
Yes is a hassle, but your privacy is worth it.
Or, do as I do:
I do not assume that my ISP does not care for my privacy...
I DO KNOW FOR A FACT that my ISP (in Venezuela) does not respect anyone's privacy (and the other ISPs do not do either, I worked at 2, and worked on an Telco Equipment seller to said ISPs, and have friends working on all the other ISPs, is a small country, and a small comunity of Telecom profesionals), but since I do not care that they can see my activities online (which are pretty harmless), I do not care and carry on with my life...
But, the important point is: Assume that every single ISP does not care about your privacy, and decide from there...
Even though my main machine is mac, and my bootcamp and windows secondary machine are on Win10 and Fully patched, and my synology NAS has SMB v1 disabled, I may as well disable SMBv1 across the whole fleet.
God have mercy on all morons who are still running unpatched machines...
Windows Embedded Standard 2009. This product is an updated release of the toolkit and componentized version of Windows XP. It was originally released in 2008, and Extended Support will end on January 8, 2019.
Windows Embedded POSReady 2009. This product for point of sale devices reflects the updates available in Windows Embedded Standard 2009. It was originally released on 2009, and extended support will end on April 9, 2019.
Since these SKU's are still based on XP, It should have been trivial for the manufacturer to certify their product to these versions released 3 and 2 years (respectively) from the planned end of support of vanilla XP (2011), and 6 and 5 years (respectively) from the effective end of support of XP (2014), without charging an arm, a leg, a kidney, and a king's ransom for it...
This "recertification" of sorts would have extended the support 8 years from the planned end of support, and 5 from the actual one. So, still, the manufacturer's fault for not doing it.
Having said that, thank you for the correction and the link, if only slashdot let me edit posts, I'd gladly edit mine, and give you credit about it.
uhh you realize last month this effected 90% of windows systems? new and old? microsoft decided that older versions of windows didnt matter anymore. even know in the 90's they convinced all kinds of Cat Scan and MRI makers to install windows XP or even worse windows SE on their machines for ease of use.. and now they refuse to give updates to people that paid $200,000-$5,000,000 for their computers. sounds like shitty business practice to me. Now i understand microsoft didnt sell the people the machines. but they did a damn good job of making sure their shitty OS was inside of them.
1.) When said CAT/MRI/CNC/'Whatevur' manufacturers decided to use XP for their equipment, they were well aware of the support lifecycle for the OS. If the support lifecycle of the OS was not enough to cover the lifecycle of the rest of the equipment, that's the manufacturer's mistake, not Microsoft's.
2.) Said lifecycle should have ended on 2011, instead, it lasted until 2014. Again, if the lifetime of the equipment connected with that computer exceeded this extended support lifetime of the OS, that's the manufacturer's mistake, not Microsoft's
3.) Many of those manufacturers (if they are still in business) are big enough to be able to negotiate a custom support agreement for said machines and therefore continue to receive patches from Microsoft to this very day (Nokia did this for our OSS and BSS equipment, this was a big deal for us in the early 2000's when WinNT4 went out of support, in my case, that was mostly the NMS10, Traffica Z1 and Performance Reporting Station, I am certain the GEs and Siemens's of this world are big enough to do this too). If the manufacturer went broke, or did not care enough about their customers to negotiate said custom support agreements for that equipment, that's the manufacturer's mistake, not Microsoft's.
4.) There is a Windows SKU Supported with security patches until 2019 (WindowsXP POS), if the manufacturers did use plain Vanilla XP instead of WinXP POS, that's the manufacturer's fault, not Microsoft's.
5.) If the manufacturer went broke before being able to develop a version of said SW compatible with new versions of the OS, or did not care to develop said version, or developed it, but decided to charge and arm and a leg and a kidney and a king's ransom for said SW, that's the manufacturer's fault, not microsoft's.
6.) If, in your tender when buying said equipment, you requested a lifetime of 15 years, failing during your due diligence to realize that the OS controlling the machine was only supported for 10 years, that mistake is yours, not Microsoft's
7.) If you, as a customer, are running any of this equipment, and even tough your manufacturer negotiated an extended support contract, or used WinXP POS, you delayed applying said patches (or even worse, disabled updates entirely), it is your fault, dear user, not Microsoft's.
8.) If you are running equipment with plain vanilla XP, with no custom support contracts, and failed to mitigate said possible risk according to manufacturer guidance and/or best practices, the fault is with yours dear user, not microsoft's. For instance, many of these systems are supposed to run on a separate network (or even airgaped), and yet I've seen them end up on a shared network with all the office equipment and lot's of shared folders to/from the rest of the network...
When techno was blaring from my office, my co-workers, peers and underlings (in latter stages), knew that I was highly focused doing something very deep (either technical, managerial, or a combination). I just turned silent my cell-phone, minimized outlook, and closed the door (I had an open door policy), and presto! no interruptions.
This, of course, was not overnight, and was aided by the fact that, while I had a cube at the begining of my career, we never worked on Open plan offices, therefore, some techno (not blaring) from the speakers, or the bleed of blaring techno from the headphones has enough of a signal.
The rest was educating people, saying: "When you hear me hearing techno, I am doing something important, do not interrupt unless is safety (fire/earthquake/flood/riots) related"
Long answer: For running Applications, you are better of with WINE. Hell, at some point even the ReactOS team realized it as such, and did a redesign to use more of the wine code and better align with the wine team.
But, since ReactOS is a re-implementation of windows, there is the niffty issue of driver support. As in: you can use old win2000/xp drivers with reactos.
It means that all those applications that use custom HARDWARE/drivers (CNC cutting SW, byte bangers, weird ISA/PCI cards) can run in a somewhat more "modern/supported" os.
Come 2019, when support for WindowsXP like systems dries out (that's when support for even Windows POS runs out, as well as those support contracts for large organizations), some (but not all) users of said hardware may consider to move to ReactOS, instead of firewalling/mitigating/baind-aiding the olden XP boxes to death.
But, judging from past experience, I doubt it. ReactOS had XP laying there as a sititng duck for 6 years, while longhorn/vista was delayed, and guess what? they were not able to catch up. Yes, chances are that by 2020 they are to the level of XP, with a little (but not all) of Win7 thrown in the mix, but do not expect more than that...
For people whose hands tremble, for whatever reason, a physical keyboard is a must.
Also, for people who have to use the phone with gloves (yes, there are glass keyboards that work with gloves, but the key targets are harder to get correctly).
So, is good that there is at least one option with decent (not great, but decent) specs, good build quality, and more or less up to date SW.
I neither think nor hope Physical KBs will make a comeback anytime soon, but I certainly hope BB/TCL keep serving the niche.
I am getting a KEYone in short order (as BB has all but abandoned BB10 devices).
My smartphones: Sonny Ericsson P800, Nokia E71, Nokia N9 (here I learned glass keyboards are not for me), BBQ10. (many Dumbphones before that, AMPS, IS132, and GSM)...
SMS has never been confidential. Is not encripted in any leg of the trip. Can be decoded from the airwaves with suitable hardware (I've seen said hardware operate first hand, 2 FPGAs, 4 DSPs, and two rugged laptops were needed in 2001, I guess nowadays a macbook with AMD laptop graphics and a SDR will be enough;-) ), can be altered via SS7 (as described in TFA), and even read easily by the operators of the telecom equipmentt, with no wizard level 100++ knowledge , or special tools:
An Example: In the SMSCs of Aldiscon/Logica/LogicaCMG/Acision (callled Telepath), one can configure how many of the characters of the SMS to reatin in the CDRs. Minimum/Default 6, max 160 characters. from there, just use grep in the CDR files to get the text of all the SMSs of any user. When I found out from the head of VAS planning, I said that was unacceptable (I was the head of operations of VAS). but, given the cavalier approach to privacy there, I decided to let sleeping dogs lie...
(the CDR also contains info like the CellID where the message was sent, but that is another story)
I am certain that other SMSCs have similar "provisions".
By the way, calling SS7/CS7 "Mobile Data BackBone", is a misnomer at best, and embarrasing dumbness at worse. Is just out of band signaling for telecom equipment coordination. Superseeded by SIGTAN/SCTP/SS7OverIP...
What is rumoured is that apple developed pretty much their whole graphics core, very different from imagination's, while the front end and some fixed functions are still imagination's IP. Either they are sure that by the time of implementation those will be developed IP free as well, or not encumbered by patetnts anymore.
Of course engineers and lawyers are fallibe, and if Imagination surveys the graphics core with a fine enough comb, they may find some nuggets of their IP there. Or be a pebble in the shoe of apple in order to get some monies...
But in the end, if push comes to shove, Apple can either settle with Imagination out of court, or buy Vivante technologies for what (for apple) is pocket lint/change, getting pattent protection in the operation.
That's strange. That is the solution that is in the box for the foreseable future.
Is updated the same way the rest of the OS is updated... Say what you want about forced updates and restarts, but if you do not trust the update mechanism (signeage of files + Method of delivery) of the OS itself, no ammount of 3rd party AV will do you any good.
I wonder how it stacks up on ASLR and DEP... but anyhow, I usae a Mac with BootCamp, so no big dealio
Slashdot Mirror
And, in the chromebook, having the option to go to a GNU/Linux full distro for full flexibility and Application Support...
And go back to GOOGLE ChromeOS if you do not like the complexity of the command line, and the multitude of choices for UI/WindowManager/InitSystem/Systemd/PulseAudio/ALSA...
And the security implications of downloading applications from anywhere not vetted in the store...
Think Grandma, or a technicaly inclined father that gets bored playing with the "Linux on chromebook" and decides to give it as a hand me down to its infant child.
As per data colection: What part of GOOGLE ChromeOS was not clear?
Pretty much the same stuff
I can not vouch for the German part, but the Spanish dictionaries in Open/LibreOffice can not hold a Candle to their MSOffice Counterparts.
If the Spelling, Grammar and thesaurus dictionaries in LibreOffice in German are as bad as their counterparts in Spanish, then is office for the win...
The English ones are serviceable. And OpenOffice originating with a German company (a loooong while ago) may help a little bit there.
And word to the wise:
If you have old or underpowered hardware (as in only two threads, and lower than Core2 Duo), do not install this, and stick to 52-ESR. The penalty for the extra context switches will kill you.
If you are in a memory restricted machine, stick to 52 ESR, as the added overhead of four processes will eat memory away, more so in the 64 bit version.
If you depend on custom NPAPI plug-ins (other than flash), stick to 52ESR, as support for NPAPI (other than flash) is blocked in 53 and onwards.
If you are on XP, stick to 52ESR (this advice is redundant, as newer versions will refuse to intall on XP without some hacking).
If there are plugins that are essential to your workflow, consider either staying on 52 ESR, or do your due diligence, as this multiprocess breaks a lot of ad-ons.
Having said all that, I am happy that firefox is moving in this direction, which I think is the right one, and will bring massive benefits for the years to come in exchange for a little disconfort and inconvenience for a short while...
I am sad that I need to stay on 52ESR (as I need a lot of IPIMI plugins, sabameeting plugins, webex plugins, and lots of other crap to be effective at work).
Hope you enjoy betatesting this for us on the ESR channel, and polishing the rough edges.
Will be seeing you guys in about a year... ;-)
Because it is the way is done in Chrome.
Now more seriously, is because of sandboxing. A process is forbiden to read or write on the memory space of another process, meanwhile every thread indide a process can read/write in the memory space of it's sister's threads (i am a spanish speaker. hebra=thread is femenine for us)...
So, if you used threads instead of processes, thread handling tab from malicious website a, coud trivially snoop/hack/crash websites in tabs b,c,d,e....
With processes, this becomes much much harder...
But in the end, is because chrome has been doing it like that since inception, and Firechrome-er i mean, fox, firefox, imitates chrome
First the usual IANAL.
But I am an electornics engineer (but not in Utah).
If you recall, Microsoft and Qualcom are using emulation to run 32bit apps. Therefore IA-32.
IA-32 is firmly intel patented. These patents are licensed to AMD under a variety of agreements, on in particular in 2001. The other side of the coin is that Intel Licenses a big chunck of AMD's AMD-64 ISA, which is not emulated by Microsoft-Qualcom.
Therefore, any claim over the use of IA-32 has to be done by intel (AMD would be more than happy to license the AMD-64 ISA for the right amount of cash).
As stated by others, in the USoA, patents only last 17 years, but remember that over the last few years we have seen, MMX, SSE, SSE2, SSE3, AVX, AVX2, virtualization support, etc. Many of those instructions exist in 32 bit SW as well. And are still covered by patents by intel. Not emulating those leads to iffy app support under emulation, so your emulation has to work "around" the patents. OR, you go to court and try to invalidate them...
So, there is a strong possibility that intel has grounds for a claim. Whether they have *enough* ground, that's a differnt story...
Of course, Microsoft and Qualcom are no pushovers whatsoever, so, it would be nice to watch a fight between those three...
But do not just assume that Intel's threat is a tiger paper...
Founder of Lowes is a Hillary supporter and contributed money to her campaign.
Founder of Home Depot is a Trump supporter and contributed money to his campaign.
These two companies form a duopoly in the home improvement stores in the US, and the Republican/Democrat parties are a duopoly in government.
Duopoly?
What About 84 Lumber?
They will bring Jobs to America
He has every right to block anyone from HIS PERSONAL @realDonaldTrump account...
He has NO right to block anyone from @POTUS.
Having said that, the legality of using his personal @realDonaldTrump account to discuss matters of state is a whole different can of worms.
PS: IANAL
Is the quote from V1 of TCATB that I read in 1996? or the quote of the current version (3.x I believe)?
Anyhow. "almost every problem will be characterized quickly". Well, this is one of the ones who forces you to use almost instead of always.
Again. FOSS is cool. and many eyes are nice. But many eyes are not a panacea or a silver bullet.
Submiter here:
You can use metasploit, which already has incorporated this bug.
From the article on "El'Reg"
"Re: Samba bug, the metasploit one-liner to trigger is just: simple.create_pipe("/path/to/target.so")"
Submitter here:
Even if machines or NASes are internal to the network, someone may send you a boobytrapped email or webpage, and infect the suceptible machines from INSIDE the network, sort of like one of the modes of contagion from the WCry worm
Submitter here.
I've been following this with a lot of attention. (here is The Register's take on the matter, by the way: https://www.theregister.co.uk/... )
And I, as many other commenters, think that the real problem is not on linux servers or Workstations with supporrted distros, for which patches already exist, but rather, on many Abandoned Distros, many cheapo NAS boxes, home Routers, IoT stuff and other dohickeys that use Linux on their firmware behind the scenes. I've a synology DS1515+ in my lab at home, and the bug was squashed on may 25, but the fix has not yet propagated to my NAS via automatic updates, but at least there is a fix (and no, SMB is not open to the Internet).
Now, think of those cheapo NAS boxes that do not see a firmware update in years, or those routers with a USB port in the back to slap a USB HDD and "share files effortlessly", or Distros like one of my old time favourites Damn Small Linux. Those are likely So Out of Luck...
No, I do not think this will be a SaMBaPOCALIPE, but I will be bad for some people.
Submitter here.
From the SUMARY: "The change will prevent clients from fully accessing some network computers and may disable some expected functions for connected Windows machines."
So, it seems that your connected Windows machines use the expected functions that the setting disables.
Go figure.
Good though to know one of the error messages that may arise after turning of the setting.
FOSS isn't a magic bullet, it's a development model. The advantages play out in statistical trends, and the differences in those trends can depend on many factors, including how 'open' development is. For example, WannaCry is somewhat comparable, and since it affected XP, the issue likely existed for at least 9 years, if not longer.
Submitter here:
I agree with you 100%. The point is that many people in the FOSS community think that the many eyes are indeed a magic bullet, and the only thing needed to weed out bugs, when, as you said, is not.
If you see my post history, you will see that my long standing oppinion is that many eyes are not enough. One needs ENOUGH Qualified AND Motivated eyes, as well as test cases and structured QA.
I came to that realization during the Metafile Fiasco of Dec. 2005.
We had two codebases, one Closed (windows) and One Open (wine). Neither was able to realize the security implications of the code. It took a third party (sysinternals IIRC) to realize the security implications. Even with many eyes, no one in the wine team realized the security implications of the metafile behaviour. At the time some people said "That's because the wine team were copying the behaviour of windows"
That is disingenuous, for if the wine team had realized the security implications, they would had bang on that drum like crazy, and made a config option of the form [metafile bug=0, 1, 2] 0=keep error for compatibility; 1=wineteam fix; 2= microsoftfix if and when released...
So, to sum up. Many eyes are nice to have, but not a panacea. For good code (less bugs, less security issues), one needs not MANY eyes but, ENOUGH QUALIFIED AND MOTIVATED EYES (of course, if you have many eyes, you MAY get ENOUGH of the eyes you need, but it is not guaranteed). Also, for good code one needs good test cases and a good QA process.
Assume no ISP respects your privacy, and act accordingly.
Maybe and ISP simply does not respect your privacy, but at least have the decency to tell you to your face, maybe the ISP "Says" it respects your privacy, but behind your back is monetizing your info, maybe they respect your privacy "Today", but are under intense financial/govermental pressure to not respect it in the future.
So, Once you decide that NO ISP is respecting your privacy (instead of asking on May 23, 2017 which ones do and which ones do not), you can act accordingly, and it does not matter anymore.
Use services that allow you to aggregate various ISPs (using MLPP) to both get a faster internet AND get the ISP of your scent, then use proxies and/or VPNs to cover your tracks, couple that with anonymizing browsers for an added level of protection. Put all the Browser crap in a RAMDISK for even more protection.
As a reader of Slashdot, you probably have the technical acumen to do it.
Yes is a hassle, but your privacy is worth it.
Or, do as I do:
I do not assume that my ISP does not care for my privacy...
I DO KNOW FOR A FACT that my ISP (in Venezuela) does not respect anyone's privacy (and the other ISPs do not do either, I worked at 2, and worked on an Telco Equipment seller to said ISPs, and have friends working on all the other ISPs, is a small country, and a small comunity of Telecom profesionals), but since I do not care that they can see my activities online (which are pretty harmless), I do not care and carry on with my life...
But, the important point is: Assume that every single ISP does not care about your privacy, and decide from there...
Even though my main machine is mac, and my bootcamp and windows secondary machine are on Win10 and Fully patched, and my synology NAS has SMB v1 disabled, I may as well disable SMBv1 across the whole fleet.
God have mercy on all morons who are still running unpatched machines...
From the link you provided:
Windows Embedded Standard 2009. This product is an updated release of the toolkit and componentized version of Windows XP. It was originally released in 2008, and Extended Support will end on January 8, 2019.
Windows Embedded POSReady 2009. This product for point of sale devices reflects the updates available in Windows Embedded Standard 2009. It was originally released on 2009, and extended support will end on April 9, 2019.
Since these SKU's are still based on XP, It should have been trivial for the manufacturer to certify their product to these versions released 3 and 2 years (respectively) from the planned end of support of vanilla XP (2011), and 6 and 5 years (respectively) from the effective end of support of XP (2014), without charging an arm, a leg, a kidney, and a king's ransom for it...
This "recertification" of sorts would have extended the support 8 years from the planned end of support, and 5 from the actual one. So, still, the manufacturer's fault for not doing it.
Having said that, thank you for the correction and the link, if only slashdot let me edit posts, I'd gladly edit mine, and give you credit about it.
uhh you realize last month this effected 90% of windows systems? new and old? microsoft decided that older versions of windows didnt matter anymore. even know in the 90's they convinced all kinds of Cat Scan and MRI makers to install windows XP or even worse windows SE on their machines for ease of use.. and now they refuse to give updates to people that paid $200,000-$5,000,000 for their computers. sounds like shitty business practice to me. Now i understand microsoft didnt sell the people the machines. but they did a damn good job of making sure their shitty OS was inside of them.
1.) When said CAT/MRI/CNC/'Whatevur' manufacturers decided to use XP for their equipment, they were well aware of the support lifecycle for the OS. If the support lifecycle of the OS was not enough to cover the lifecycle of the rest of the equipment, that's the manufacturer's mistake, not Microsoft's.
2.) Said lifecycle should have ended on 2011, instead, it lasted until 2014. Again, if the lifetime of the equipment connected with that computer exceeded this extended support lifetime of the OS, that's the manufacturer's mistake, not Microsoft's
3.) Many of those manufacturers (if they are still in business) are big enough to be able to negotiate a custom support agreement for said machines and therefore continue to receive patches from Microsoft to this very day (Nokia did this for our OSS and BSS equipment, this was a big deal for us in the early 2000's when WinNT4 went out of support, in my case, that was mostly the NMS10, Traffica Z1 and Performance Reporting Station, I am certain the GEs and Siemens's of this world are big enough to do this too). If the manufacturer went broke, or did not care enough about their customers to negotiate said custom support agreements for that equipment, that's the manufacturer's mistake, not Microsoft's.
4.) There is a Windows SKU Supported with security patches until 2019 (WindowsXP POS), if the manufacturers did use plain Vanilla XP instead of WinXP POS, that's the manufacturer's fault, not Microsoft's.
5.) If the manufacturer went broke before being able to develop a version of said SW compatible with new versions of the OS, or did not care to develop said version, or developed it, but decided to charge and arm and a leg and a kidney and a king's ransom for said SW, that's the manufacturer's fault, not microsoft's.
6.) If, in your tender when buying said equipment, you requested a lifetime of 15 years, failing during your due diligence to realize that the OS controlling the machine was only supported for 10 years, that mistake is yours, not Microsoft's
7.) If you, as a customer, are running any of this equipment, and even tough your manufacturer negotiated an extended support contract, or used WinXP POS, you delayed applying said patches (or even worse, disabled updates entirely), it is your fault, dear user, not Microsoft's.
8.) If you are running equipment with plain vanilla XP, with no custom support contracts, and failed to mitigate said possible risk according to manufacturer guidance and/or best practices, the fault is with yours dear user, not microsoft's. For instance, many of these systems are supposed to run on a separate network (or even airgaped), and yet I've seen them end up on a shared network with all the office equipment and lot's of shared folders to/from the rest of the network...
So, let's put blame where blame is.
If the NSA, CIA, FBI and Five eyes all can see my Pr0n browsing history, why can't the FSB joint the fun too?
When techno was blaring from my office, my co-workers, peers and underlings (in latter stages), knew that I was highly focused doing something very deep (either technical, managerial, or a combination). I just turned silent my cell-phone, minimized outlook, and closed the door (I had an open door policy), and presto! no interruptions.
This, of course, was not overnight, and was aided by the fact that, while I had a cube at the begining of my career, we never worked on Open plan offices, therefore, some techno (not blaring) from the speakers, or the bleed of blaring techno from the headphones has enough of a signal.
The rest was educating people, saying: "When you hear me hearing techno, I am doing something important, do not interrupt unless is safety (fire/earthquake/flood/riots) related"
Short answer: NO!
Long answer: For running Applications, you are better of with WINE. Hell, at some point even the ReactOS team realized it as such, and did a redesign to use more of the wine code and better align with the wine team.
But, since ReactOS is a re-implementation of windows, there is the niffty issue of driver support. As in: you can use old win2000/xp drivers with reactos.
It means that all those applications that use custom HARDWARE/drivers (CNC cutting SW, byte bangers, weird ISA/PCI cards) can run in a somewhat more "modern/supported" os.
Come 2019, when support for WindowsXP like systems dries out (that's when support for even Windows POS runs out, as well as those support contracts for large organizations), some (but not all) users of said hardware may consider to move to ReactOS, instead of firewalling/mitigating/baind-aiding the olden XP boxes to death.
But, judging from past experience, I doubt it. ReactOS had XP laying there as a sititng duck for 6 years, while longhorn/vista was delayed, and guess what? they were not able to catch up. Yes, chances are that by 2020 they are to the level of XP, with a little (but not all) of Win7 thrown in the mix, but do not expect more than that...
For people whose hands tremble, for whatever reason, a physical keyboard is a must.
Also, for people who have to use the phone with gloves (yes, there are glass keyboards that work with gloves, but the key targets are harder to get correctly).
So, is good that there is at least one option with decent (not great, but decent) specs, good build quality, and more or less up to date SW.
I neither think nor hope Physical KBs will make a comeback anytime soon, but I certainly hope BB/TCL keep serving the niche.
I am getting a KEYone in short order (as BB has all but abandoned BB10 devices).
My smartphones: Sonny Ericsson P800, Nokia E71, Nokia N9 (here I learned glass keyboards are not for me), BBQ10. (many Dumbphones before that, AMPS, IS132, and GSM)...
SMS has never been confidential. Is not encripted in any leg of the trip. Can be decoded from the airwaves with suitable hardware (I've seen said hardware operate first hand, 2 FPGAs, 4 DSPs, and two rugged laptops were needed in 2001, I guess nowadays a macbook with AMD laptop graphics and a SDR will be enough ;-) ), can be altered via SS7 (as described in TFA), and even read easily by the operators of the telecom equipmentt, with no wizard level 100++ knowledge , or special tools:
An Example:
In the SMSCs of Aldiscon/Logica/LogicaCMG/Acision (callled Telepath), one can configure how many of the characters of the SMS to reatin in the CDRs. Minimum/Default 6, max 160 characters. from there, just use grep in the CDR files to get the text of all the SMSs of any user. When I found out from the head of VAS planning, I said that was unacceptable (I was the head of operations of VAS). but, given the cavalier approach to privacy there, I decided to let sleeping dogs lie...
(the CDR also contains info like the CellID where the message was sent, but that is another story)
I am certain that other SMSCs have similar "provisions".
By the way, calling SS7/CS7 "Mobile Data BackBone", is a misnomer at best, and embarrasing dumbness at worse. Is just out of band signaling for telecom equipment coordination. Superseeded by SIGTAN/SCTP/SS7OverIP...
What is rumoured is that apple developed pretty much their whole graphics core, very different from imagination's, while the front end and some fixed functions are still imagination's IP. Either they are sure that by the time of implementation those will be developed IP free as well, or not encumbered by patetnts anymore.
Of course engineers and lawyers are fallibe, and if Imagination surveys the graphics core with a fine enough comb, they may find some nuggets of their IP there. Or be a pebble in the shoe of apple in order to get some monies...
But in the end, if push comes to shove, Apple can either settle with Imagination out of court, or buy Vivante technologies for what (for apple) is pocket lint/change, getting pattent protection in the operation.
whichever is cheaper.
The parent post mentions SGI iron.
but also let's not forget multitude of routing equipment (CISCO was/is a big user of MIPS processors).
Also, the Chinese have developed MIPS processors for use in anything from laptops to SuperComputers... (Loongson/Godson).
MIPS cores are also used in many cheapo routers/modems
That's strange. That is the solution that is in the box for the foreseable future.
Is updated the same way the rest of the OS is updated... Say what you want about forced updates and restarts, but if you do not trust the update mechanism (signeage of files + Method of delivery) of the OS itself, no ammount of 3rd party AV will do you any good.
I wonder how it stacks up on ASLR and DEP... but anyhow, I usae a Mac with BootCamp, so no big dealio