Honestly I don't know. But the number of systems still running a vulnerable version of OpenSSL is non-trivial...
In any case, the primary reason for dropping OpenSSL support is limited developer resources - GNU TLS is a lot easier to interface with and support certificate validation than OpenSSL. Nothing says the old OpenSSL support could not be brought back, but there is basically no advantage in doing so.
Optimistically, fax represents 0.0004% of daily usage of printers from computers. Most fax happens directly at the printer with hardcopy getting fed in. And most people in the printing industry have been hoping/praying that fax will die for like 20 years now. The only reason for its continued existence is the questionable legal standing that faxed documents are valid and safe for contracts and medical information while secure transport over the Internet (TLS, PGP, etc.) is not.
Scan gets slightly more usage than fax, but since no vendor implements a public standard scanning protocol (possibly to change with the IPP Scan spec in formal vote right now? I dunno) and since scan works in the opposite direction as print, I don't see a version of CUPS that does both print and scan coming any time soon. Plus you don't have the same spooling requirements for scan - just pull the scan data from the printer and stuff it in a file from a user application.
Of the ~500 million printers in active service today (that's counting all of the printers sold in the last 4 years, since the average service life of a printer is a little over 4 years overall), 96% have one or more network interfaces and 94% support IPP (the holdouts are mainly label printers...)
Most IPP printers support PostScript, PCL, PDF, PWG Raster, or AirPrint, which means you can do a "generic" driver that provides all or most (depending on the printer and language) of the functionality of the vendor's printer driver, with more functionality being available in newer printers.
The last holdout is USB printing (USB only printers account for about 4% of all printers sold these days), where we can use IPP over USB to eliminate drivers. IPP USB support started showing up in 2014 printers, and the latest Ubuntu and OS X support it automatically.
File bugs or email the webmaster if you have trouble with a web site.
In the case of CUPS.org, it is using Bootstrap and the intent is for the navigation to switch to a vertical menu (that can be hidden) when the width gets too narrow. There should be enough space to keep the regular menu "bar" down to 768 pixels wide at least, and if that is breaking you need to tell the CUPS.org webmaster about it, otherwise it won't get fixed...
IPP doesn't use XML, it uses a (flat) binary message encoding. I imagine that had IPP been developed a few years later things would have been different... And while it definitely supports what is needed in the enterprise, it also satisfies the consumer space - ~500 million printers in service today (from consumer inkjets to big iron office copiers) support IPP, as does *every* consumer and enterprise computer and mobile device (billions of devices). IPP scales well.
The problem with LPRng was that it was a mess of scripts and hacks to make a variety of printers work. Every "driver" worked differently, and (having spent a fair amount of time with it 20 years ago) making it all work without an expert supporting it was basically impossible. It continued to use an extended version of the LPD protocol (which has nothing other than an informative RFC to document it, with most implementations varying from the RFC in some way) and did not address some pretty basic security issues like hiding job information from other users.
Back in 1998 there was little support for standard languages or doing a proper protocol so that you could monitor a printer's state or cancel a job. Vendors used proprietary languages and protocols to lock you into their drivers, their platform, their products. The whole point of CUPS was to define a standard interface with standard options for drivers while providing a better security model. Yes, that did make it more complicated than LPD/LPRng, but that complexity was needed since printing is *hard* and the software needed to support it is non-trivial. IPP was chosen as the underlying protocol and model because it offered everything needed from regular users to enterprise.
Ultimately CUPS succeeded because it allowed people to print without becoming experts. It allowed Linux distributors to actually support printing, and for printer manufacturers and third parties to provide drivers that "just worked". And it did it using public standards and the very UNIX-y interface of piped commands.
While CUPS continues to carry some old baggage around to keep supporting old printers, the day will come when that is no longer necessary and a leaner version (possibly based on the ippserver code) will be able to replace it. Today the economics favor printers implementing common, open standards so that all platforms can support them without extra, expensive development. Within a few years, it should be possible to retire printer drivers entirely.
The recent OpenSSL vulnerabilities were just the nail in the coffin. It was more a matter of limited developer resources and the relative difficulty of implementing certification validation with the OpenSSL APIs vs. GNU TLS. (and don't forget we also support SecureTransport on OS X and Schannel on Windows...)
Much better to focus on making support for one popular TLS library on Linux/*BSD than to do a half-assed job for two libraries, one of which has known vulnerabilities and API/forking issues.
Free apps with in-app purchases show that fact right under the 'Buy' button. And a simple setting controls whether in-app purchases are allowed at all, require approval, or can go through automatically (default is require approval). And iOS 8 has the proxy stuff for family accounts (parental approval for everything if you want).
RFC 2817 defines how a server (or a client) can require TLS. It is widely deployed for printers but less so on the Internet due to proxies not supporting it.
and Google, Apple, etc. are providing mass transit from one city to another within the region. I used to commute (drive) from the South bay (Morgan Hill) to Cupertino daily, which (on a good day) meant 1.5 hours of driving to go 30 miles. I couldn't afford to live in (and frankly didn't like) Cupertino, and the mass transit in the bay area is a joke (I'd be looking at 3 hours between the train and bus for the same commute).
When Apple started their bus service I used it and never looked back. And doing so eliminated (at the time) about 150 cars from the road for a single route, and there are now (I think) 10 different direct routes, with double-decker buses (80 vs. 50 people per bus) plus shuttle service to traditional mass transit locations.
If anything, the new buses and shuttles have probably only served to increase ridership on public transit while removing a shitload of cars from the road. How is that bad, exactly?
> (LLVM attracts some investment, such as that of Apple, up to a certain point, because Apple's goal is to undermine GCC.)
No, Apple's goal (like most businesses) is to avoid the GPL3 because it is decidedly unfriendly to business. Plus it doesn't help that the GCC project has a long history of being unfriendly to outside developers in general (remember EGCS?) and wanted nothing to do with OpenGL/OpenCL which use a C-like language for shaders and other GPU code. And when LLVM is as good or better than GCC, it doesn't take a genius to switch.
I'm sure there are many who are concerned about the long-term effects of GMO crops on the viability of non-GMO crops (cross-pollination between fields, economic factors, strong-arming by companies that produce GMO seed, etc.), but I am more concerned with the primary usage of GMO, at least in North America - herbicide resistance. With ordinary seed you might still use herbicides to control weeds, but overall you can't use much because you'll kill your crop. Use a GMO seed that is engineered to not be susceptible to those herbicides and now you can use a bunch more to ensure that those pesky weeds don't reduce the yield of your crops. We already know that most herbicides, pesticides, and fungicides are bad for people, yet we seem to be rushing forward to use more of them...
It would be better to require labeling of GMO products and the 'cides that have been used in their production... Then let the market/consumers decide which products they want to buy...
We default to localhost for security reasons - most systems are clients/not sharing printers, so why expose your system to the world/office?
Run "cupsctl --remote-admin --remote-any --share-printers WebInterface=Yes" after you install to enable remote access, share printers, and enable the web interface. Add "DefaultEncryption=Never" if you don't want to use SSL/TLS (although personally I don't recommend that - encryption comes "for free" these days...)
Have any links for the gender divide? In my family me and my brother in laws have ipad minis but all the women have the full sized iPads. We chose the mini because it is more convenient to cart around and is the first ipad (first tablet?) close to the Star Trek pads; one of my brother in laws is an electrician and uses it (in a suitable case) on the job - full code reference, notes for the current job, etc. So I'm not sure gender is a factor here, but cost and the right size/weight for a particular usage.
I've never bought organic for the taste or nutrition, I'm more concerned with pesticide and "buddnip" use on non-organic produce. The best place to get your veggies (aside from your own garden) is a local farm/farmers market (although for the latter be careful to find out where vendors are getting their produce from...)
CUPS 1.6 (and the next 1.5.x) will support "Bonjour" discovery using Avahi on Linux and other platforms (in addition to mDNSResponder, which is also open source and works just dandy on the same platforms...)
The problem with CUPS Browsing is that it relies on UDP Broadcasts, which are bad for Wi-Fi bandwidth and power consumption. CUPS Browsing also has issues with hostnames - how do you setup a network using CUPS Browsing without broadcasting IP addresses (printer@11.22.33.44?? Yeck), setting up a DNS server, or syncing/etc/hosts files? All of those things are solved by Bonjour (mDNS, Zeroconf, DNS-SD)
FLTK (www.fltk.org) is still in active development and is my cross-platform toolkit of choice - C++-based, easy to use, and works on Windows, Linux, and Mac OS X with ports for other platforms available.
OK, so lets put a metal shipping container (i.e. a big metal box) out in the desert and have people sit in there throughout the day - won't that get awfully hot?!?
Roundabouts are not a great thing to have with snow and ice - doing a sequence of tight turns can easily result in loss of control and an accident, not to mention that they suck when you have a lot of traffic.
Slashdot Mirror
Honestly I don't know. But the number of systems still running a vulnerable version of OpenSSL is non-trivial...
In any case, the primary reason for dropping OpenSSL support is limited developer resources - GNU TLS is a lot easier to interface with and support certificate validation than OpenSSL. Nothing says the old OpenSSL support could not be brought back, but there is basically no advantage in doing so.
Optimistically, fax represents 0.0004% of daily usage of printers from computers. Most fax happens directly at the printer with hardcopy getting fed in. And most people in the printing industry have been hoping/praying that fax will die for like 20 years now. The only reason for its continued existence is the questionable legal standing that faxed documents are valid and safe for contracts and medical information while secure transport over the Internet (TLS, PGP, etc.) is not.
Scan gets slightly more usage than fax, but since no vendor implements a public standard scanning protocol (possibly to change with the IPP Scan spec in formal vote right now? I dunno) and since scan works in the opposite direction as print, I don't see a version of CUPS that does both print and scan coming any time soon. Plus you don't have the same spooling requirements for scan - just pull the scan data from the printer and stuff it in a file from a user application.
Of the ~500 million printers in active service today (that's counting all of the printers sold in the last 4 years, since the average service life of a printer is a little over 4 years overall), 96% have one or more network interfaces and 94% support IPP (the holdouts are mainly label printers...)
Most IPP printers support PostScript, PCL, PDF, PWG Raster, or AirPrint, which means you can do a "generic" driver that provides all or most (depending on the printer and language) of the functionality of the vendor's printer driver, with more functionality being available in newer printers.
The last holdout is USB printing (USB only printers account for about 4% of all printers sold these days), where we can use IPP over USB to eliminate drivers. IPP USB support started showing up in 2014 printers, and the latest Ubuntu and OS X support it automatically.
File bugs or email the webmaster if you have trouble with a web site.
In the case of CUPS.org, it is using Bootstrap and the intent is for the navigation to switch to a vertical menu (that can be hidden) when the width gets too narrow. There should be enough space to keep the regular menu "bar" down to 768 pixels wide at least, and if that is breaking you need to tell the CUPS.org webmaster about it, otherwise it won't get fixed...
IPP doesn't use XML, it uses a (flat) binary message encoding. I imagine that had IPP been developed a few years later things would have been different... And while it definitely supports what is needed in the enterprise, it also satisfies the consumer space - ~500 million printers in service today (from consumer inkjets to big iron office copiers) support IPP, as does *every* consumer and enterprise computer and mobile device (billions of devices). IPP scales well.
The problem with LPRng was that it was a mess of scripts and hacks to make a variety of printers work. Every "driver" worked differently, and (having spent a fair amount of time with it 20 years ago) making it all work without an expert supporting it was basically impossible. It continued to use an extended version of the LPD protocol (which has nothing other than an informative RFC to document it, with most implementations varying from the RFC in some way) and did not address some pretty basic security issues like hiding job information from other users.
Back in 1998 there was little support for standard languages or doing a proper protocol so that you could monitor a printer's state or cancel a job. Vendors used proprietary languages and protocols to lock you into their drivers, their platform, their products. The whole point of CUPS was to define a standard interface with standard options for drivers while providing a better security model. Yes, that did make it more complicated than LPD/LPRng, but that complexity was needed since printing is *hard* and the software needed to support it is non-trivial. IPP was chosen as the underlying protocol and model because it offered everything needed from regular users to enterprise.
Ultimately CUPS succeeded because it allowed people to print without becoming experts. It allowed Linux distributors to actually support printing, and for printer manufacturers and third parties to provide drivers that "just worked". And it did it using public standards and the very UNIX-y interface of piped commands.
While CUPS continues to carry some old baggage around to keep supporting old printers, the day will come when that is no longer necessary and a leaner version (possibly based on the ippserver code) will be able to replace it. Today the economics favor printers implementing common, open standards so that all platforms can support them without extra, expensive development. Within a few years, it should be possible to retire printer drivers entirely.
The recent OpenSSL vulnerabilities were just the nail in the coffin. It was more a matter of limited developer resources and the relative difficulty of implementing certification validation with the OpenSSL APIs vs. GNU TLS. (and don't forget we also support SecureTransport on OS X and Schannel on Windows...)
Much better to focus on making support for one popular TLS library on Linux/*BSD than to do a half-assed job for two libraries, one of which has known vulnerabilities and API/forking issues.
Free apps with in-app purchases show that fact right under the 'Buy' button. And a simple setting controls whether in-app purchases are allowed at all, require approval, or can go through automatically (default is require approval). And iOS 8 has the proxy stuff for family accounts (parental approval for everything if you want).
How is this Apple 'doing nothing'?
RFC 2817 defines how a server (or a client) can require TLS. It is widely deployed for printers but less so on the Internet due to proxies not supporting it.
and Google, Apple, etc. are providing mass transit from one city to another within the region. I used to commute (drive) from the South bay (Morgan Hill) to Cupertino daily, which (on a good day) meant 1.5 hours of driving to go 30 miles. I couldn't afford to live in (and frankly didn't like) Cupertino, and the mass transit in the bay area is a joke (I'd be looking at 3 hours between the train and bus for the same commute).
When Apple started their bus service I used it and never looked back. And doing so eliminated (at the time) about 150 cars from the road for a single route, and there are now (I think) 10 different direct routes, with double-decker buses (80 vs. 50 people per bus) plus shuttle service to traditional mass transit locations.
If anything, the new buses and shuttles have probably only served to increase ridership on public transit while removing a shitload of cars from the road. How is that bad, exactly?
and other "add-ons" in the same spirit?
> (LLVM attracts some investment, such as that of Apple, up to a certain point, because Apple's goal is to undermine GCC.)
No, Apple's goal (like most businesses) is to avoid the GPL3 because it is decidedly unfriendly to business. Plus it doesn't help that the GCC project has a long history of being unfriendly to outside developers in general (remember EGCS?) and wanted nothing to do with OpenGL/OpenCL which use a C-like language for shaders and other GPU code. And when LLVM is as good or better than GCC, it doesn't take a genius to switch.
I'm sure there are many who are concerned about the long-term effects of GMO crops on the viability of non-GMO crops (cross-pollination between fields, economic factors, strong-arming by companies that produce GMO seed, etc.), but I am more concerned with the primary usage of GMO, at least in North America - herbicide resistance. With ordinary seed you might still use herbicides to control weeds, but overall you can't use much because you'll kill your crop. Use a GMO seed that is engineered to not be susceptible to those herbicides and now you can use a bunch more to ensure that those pesky weeds don't reduce the yield of your crops. We already know that most herbicides, pesticides, and fungicides are bad for people, yet we seem to be rushing forward to use more of them...
It would be better to require labeling of GMO products and the 'cides that have been used in their production... Then let the market/consumers decide which products they want to buy...
Under Settings->General->Accessibility->LED Flash for Alerts
We default to localhost for security reasons - most systems are clients/not sharing printers, so why expose your system to the world/office?
Run "cupsctl --remote-admin --remote-any --share-printers WebInterface=Yes" after you install to enable remote access, share printers, and enable the web interface. Add "DefaultEncryption=Never" if you don't want to use SSL/TLS (although personally I don't recommend that - encryption comes "for free" these days...)
That covers 7-inch (non-iPad mini) users of those magazines, but not iPad mini users (which they mention near the end...)
Have any links for the gender divide? In my family me and my brother in laws have ipad minis but all the women have the full sized iPads. We chose the mini because it is more convenient to cart around and is the first ipad (first tablet?) close to the Star Trek pads; one of my brother in laws is an electrician and uses it (in a suitable case) on the job - full code reference, notes for the current job, etc. So I'm not sure gender is a factor here, but cost and the right size/weight for a particular usage.
On iDevices you can do this with a four finger swipe...
I was wondering about victims of child abuse wanting to tell their stories...
I've never bought organic for the taste or nutrition, I'm more concerned with pesticide and "buddnip" use on non-organic produce. The best place to get your veggies (aside from your own garden) is a local farm/farmers market (although for the latter be careful to find out where vendors are getting their produce from...)
CUPS 1.6 (and the next 1.5.x) will support "Bonjour" discovery using Avahi on Linux and other platforms (in addition to mDNSResponder, which is also open source and works just dandy on the same platforms...)
The problem with CUPS Browsing is that it relies on UDP Broadcasts, which are bad for Wi-Fi bandwidth and power consumption. CUPS Browsing also has issues with hostnames - how do you setup a network using CUPS Browsing without broadcasting IP addresses (printer@11.22.33.44?? Yeck), setting up a DNS server, or syncing /etc/hosts files? All of those things are solved by Bonjour (mDNS, Zeroconf, DNS-SD)
The 5-computer limit does not apply to applications, only to music and video content. You can even re-download apps later as needed (same as iOS).
FLTK (www.fltk.org) is still in active development and is my cross-platform toolkit of choice - C++-based, easy to use, and works on Windows, Linux, and Mac OS X with ports for other platforms available.
OK, so lets put a metal shipping container (i.e. a big metal box) out in the desert and have people sit in there throughout the day - won't that get awfully hot?!?
Roundabouts are not a great thing to have with snow and ice - doing a sequence of tight turns can easily result in loss of control and an accident, not to mention that they suck when you have a lot of traffic.
Yeah, since the roads will be glass they'll replace the plows with big squeegees.