mfryd

Physical SIMs pose a security risk.  If someone steals your iPhone, they likely can't unlock it to get to your personal data, but they can easily remove a physical SIM, and place it in an unlocked phone.  Once the physical SIM is in their unlocked phone, they get all of your SMS messages.   Including SMS messages used to verify identity when they want to reset a password, or otherwise break into your online financial accounts, social media accounts, etc.

I think the author of this article is reading too much into Bob Borchers' statement. While Apple may very well be working on an Apple Silicon based Mac Pro.  I don't think Bob Borchers' statement speaks to that issue.

"Taking the entire product line to Apple Silicon" might mean that any Mac model with an Intel processor will be discontinued.  This doesn't seem to be a statement that every Mac model will survive the transition.

bloggerblog said:

That’s could become a controversial move since Tesla is a public traded company and Twitter is his private company. So borrowing employees from a public company can get weird. 

There are many ways this could be structured.  

For instance, Twiter could hire Tesla to do the software development.  Twitter would pay Tesla, and Tesla employees would handle the work.   

I don't see anything "weird" with Tesla expanding the experience level of their in-house software developers by having them work on a different type of project for a few weeks.  Such a move might very well benefit Tesla in the long run, as their developers will gain experience in new areas, that might be applicable to Tesla's car business.  Furthermore, allowing their developers a break might allow them to come back in a few weeks with fresh perspectives on their Tesla projects.

On the other hand, one could make a case that it is not in the stockholder's best interests for Tesla to take on this sort of software engineering project.  That's a topic on which reasonable people can disagree.

macplusplus said:

mfryd said:

macplusplus said:

PDF is based on PostScript but a PDF file is different from .ps file. A .ps file is printer-dependent, PDF is printer-independent. Since .ps is generated by the printer driver, it includes all the setup environment specific to the printer and it will fail on another printer. Preview is PDF, it cannot be otherwise because Quartz, the very graphic core of macOS, is based on PDF. So PDF is intrinsic to macOS and it will remain so until another graphic model replaces Quartz.

I found myself of thirty years ago in your long post. Imagesetters have (mostly) separate RIPs that can process many file types, including all .ps files. In the most simplistic terms, a .ps file is generated by the printer driver. Create a .ps file with Apple driver and upload it directly into a HP printer via Ethernet, it will fail. This is PostScript language which is device independent, not what is written to the file. What is written to the file depends on the printer driver, i.e printer model. Printer drivers were specific to each printer because printer ROMs from each brand were different. Otherwise a universal driver would do the job. Later PPD files have been released to handle such issues.

Prior to PostScript the files would need to be customized for each printer driver.

PostScript allowed the creation of files that would work on any PostScript printer.

PostScript tried to do everything.  In addition to a Page Description Language, it also had printer control features (i.e. pull the first page from Tray #1, and the remaining pages from Tray#2).  PostScript Printer Description (PPD) files would describe the specific capabilities of a printer.  The PPD printer would describe how many input trays the printer had, whether it had manual feed, duplex, color, or even a stapler.   The printer driver could then send a few lines of PostScript before sending the file to request device specific features.  


The challenge with PostScript files generated by the Mac Printer driver is that they were not stand-alone legal PostScript files.  Remember, PostScript is a programming language, and the Mac printer driver relied on a library of routines that emulated Apple's QuickDraw imaging system.  Rather than embedding that library in every file, the Mac sent it once, and it remained on the printer for subsequent prints.   

macplusplus said:

PDF is based on PostScript but a PDF file is different from .ps file. A .ps file is printer-dependent, PDF is printer-independent. Since .ps is generated by the printer driver, it includes all the setup environment specific to the printer and it will fail on another printer. Preview is PDF, it cannot be otherwise because Quartz, the very graphic core of macOS, is based on PDF. So PDF is intrinsic to macOS and it will remain so until another graphic model replaces Quartz.

PDF (Portable Document Format) is essentially a subset of PostScript.   Both PostScript® and PDF are printer independent.  

Device independence was one of the great innovations of PostScript.  The exact same PostScript file could be sent to a 300 dpi laser printer, or a 2540 dpi LinoType® Image Setter.  It was a godsend to be able to easily proof files on a laser printer, before sending them to an image setter to be rendered onto expensive photographic film (or direct to printing plates).  Prior to PostScript print files had to be custom generated for the brand and model of printer to be used.  Furthermore, the selection of available fonts varied from printer to printer.

Even hardware specific aspects (like duplexing) are standard across different printers.  With a properly written PostScript file, you can request duplexing, and have it print simplex on printers without that feature.  Similarly, a color PostScript will simply print in B&W on a B&W laser printer.  With PostScript you can even specify the halftone screen dot shape in a hardware independent manner.


PostScript is both a Page Description Language and a Programming Language.  The Page Description features allows the specification of how the page should look in a manner that is independent from the specifics of the printer.  

The Programming Language aspects are both a blessing and a curse.  The first PostScript printer was the Apple LaserWriter.   At the time, the Mac internally used QuickDraw for graphics.  They wrote a QuickDraw emulator in PostScript which allowed the library of existing Mac applications to print.  That was the blessing.

The curse was that programs in PostScript could take an arbitrarily long time to run.  If the printer was being asked to do a lot of computation, a printer rate at 40 pages per minute might only print 12 pages per minute.

The programming features also allowed the creation of files that altered the results depending on the printer being used (but this was rare).  For instance, a file that needed to absolutely maximize printing precision, could fine tune the placement and size of graphics to conform to the hardware pixels of the printer being used.  If you sent the file to a 300ppi printer, the adjustments could be up to 1/300 of an inch.  On a 2540 dpi image setter, the adjustments would be less than 1/2540 of an inch.

PDF is essentially PostScript, with the programming aspects removed.   it's easier and simpler to write something that understands PDF than the full PostScript language.

Of course, without the programming aspects, PostScript and Adobe wouldn't exist.   The idea for PostScript came about when Warnock and Geschke were working at Xerox.  Xerox liked the device independent aspects, but hated the programability.  If Xerox sold a 120 page per minute printer, they didn't want a language with programing that could slow it down.  Warnock and Geschke felt strongly about programability, and left to form Adobe systems.  Xerox developed InterPress, which was their proprietary version without programability.   Adobe got Apple on board, as the programability meant the LaserWrite could be taught to understand the QuickDraw primitives.   At the time, the processor in the LaserWriter was about as powerful (if not more powerful) than the processor in the Mac.

Modern Macs internally use PDF.  It's easy to convert from PDF into PostScript.   By the way, if you want an idea of the sorts of graphic primitives found in PostScript, just look at Adobe Illustrator.  The primitives in Illustrator pretty much line up with the primitives in PostScript (Bezier curves, fills, stokes, dashed lines, clipping paths,...)