Preview.app in NeXTstep used to have a postscript window where you could type in postscript (or paste it in) and interactively work with it. It was an essential development tool to help write postscript before including it in a source code file as a pswrap.
I didn't know that! Is it announced somewhere, even buried deep in release notes, or just one of those things that they decided silently to enshittify?
Oh man. I used PostScript a ton when I worked at hp 20 years ago. It's actually a pretty great language, like lisp/scheme but I found it to be more approachable somehow. Maybe because it's postfix instead of prefix?
Anyway, it had several fatal flaws. I don't think it could handle images natively, so instead it encoded them as vectors and those files took up MB. It probably just needed a metaphor like iframe.
I remember when Apple switched to the PDF engine in Quartz in preparation for OS X in the late 90s, I thought it was a mistake then. The QuickDraw it was replacing was actually quite good, in some ways the epitome of C-style rendering. And Cocoa was refreshing at first (it handled stuff like palettes and gamma in a data-driven way instead of through leaky abstractions) but without a way to transition off QuickDraw, it felt like more busywork that had to be done just to keep up.
Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
> Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
Eh, I'm with Apple on this one: we can just use Ghostscript. Apple's move effectively forces the few applications that need to use PostScript on macOS to migrate from a proprietary PostScript implementation to an OSS one, which strikes me as ultimately a good thing.
> .. with vibe coding we can just whip up a Preview app
why deflate your own position with this (worthless-untrue-spineless) statement? Which library is doing the work? who writes that library and maintains it?
that was a real product with ordinary thousands of hours of skilled coding in there.. That is certainly the part that is doing work. Secondly someone really knows what they are doing to slip in those architectural layers / shims / pipes .. Very impressive IMHO
Yes, PostScript is a great general purpose high level programming language, kind of like a cross between Forth and Lisp, but a lot more like Lisp, with its polymorphic homoiconic data structures that were essentially JSON.
>PostScript is kind of like a cross between Forth and Lisp, but a lot more like Lisp actually. And its data structures, which also represent its code, are essentially s-expressions or JSON (polymorphic dicts, arrays, numbers, booleans, nulls, strings, names (interned strings), operators (internal primitives), etc.)
>Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc).
>You're welcome! OOPS (Object Oriented PostScript ;), I meant to say that PostScript and Lisp are homoiconic, but Forth is not. The PSIBER paper on medium goes into that (but doesn't mention the word homoiconic, just describes how PS data structures are PS code, so a data editor is a code editor too).
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989:
>PostScript is often compared to Forth, but what it lacks in relation
to Forth is a user-extensible compiler. You can write your own
PostScript control structures and whatnot, like case and cond, to
which you pass procedures as arguments on the stack, but the
PostScript scanner is not smart -- but there is no preprocessing done
to the PostScript text being read in, like the way immediate words in
Forth can take control and manipulate the contents of the dictionary
and stack while the text source is being read in and compiled, or like
the way Lisp macros work. This is one of the things I would like to
be able to do with something like LispScript.
>"Lisp is the language for people who want everything, and are willing to pay for it." -Russell Brand (the old school Lisp hacker "wuthel" from MIT, not the crazy MAGA rapist)
If you want to efficiently implement a PostScript interpreter with rendering in the web browser (or node), you just have to reach for the canvas 2d rendering context, which is essentially the full PostScript stencil/paint imaging model upgraded to the Porter/Duff compositing model with alpha channels, but without the user defined font rendering and halftoning machinery (which you could implement on top of it).
PostScript has always had the black and white "image" and "imagemask" operators, but they are clumsy, don't support any kind of image processing, and you have to use "readhexstring" to read hex images, but later versions support color images.
NeWS has "readcanvas" to directly read binary Sun raster files (including color) from files and over the network. It also had memory mapped canvases, which I used for the HyperLook version of SimCity so the C simulator engine could efficiently render the tiles and map views with overlays into memory, and NeWS could scale and render them quickly. I also used memory mapped canvases for my NeWS/HyperLook cellular automata machine, which was implemented in C and scaled and rendered and had a real time painting UI implemented in NeWS PostScript (the client and server took turns "owning" the pixels by ping-ponging messages over the localhost network, so each could draw into the cells in turn, and you could render PostScript directly into the 8-bit color cells for interesting effects, melt people's faces, and clip them on the screen to a window in the shape of a lava lamp).
The Apple PostScript printer drivers used (and Adobe's Blue Book documented) an indirect but efficient hack that tricked the custom halftone rendering machinery into performing a perfect pattern fill (so you could print MacDraw files, etc).
DonHopkins on March 13, 2020 | parent | context | favorite | on: Finding Mona Lisa in the Game of Life
Error diffusion dithering would work very well as initial conditions for many cellular automata rules like Life, especially counting rules (which life is) that stay alive with intermediate numbers of neighbors.
Conway's Life stays alive with 2 or 3 neighbors out of 9, or 2/9 .. 3/9, so gray scales between 22% .. 33% would be the most active.
Halftone screens would have different results, but their regularity might work well with certain CA rules and screens.
PostScript gives you a lot of control over the halftone screen definition.
Halftone screens can use any kind of repeating pattern, there just has to be the proper ratio of white to black pixels to make it look the right brightness. You could even design a set of halftone screen patterns that were precisely matched with a particular cellular automata rule to produce interesting fertile or static patterns. And you can even use any arbitrary pattern for each level, even if they aren't the right brightness, for aesthetic reasons.
The original PostScript LaserWriter was able to efficiently perform pattern fills to print tiled MacDraw images, by defining a custom halftone screen for each tile pixel pattern, that printed precisely the right pixels when you set just the right gray level: the ratio of on pixels to the total number of pixels in the tile. The spot function basically tells the halftone screen machinery what order to turn the dots on as the gray level goes from 1 to 0 (which results is seamless tiling with nearby gray tiles). Take a look at the PostScript header of an old MacDraw file some time to see the really bizarre code that does that by abusing the "setscreen" operator with a contrived spot function. (That was extremely tricky and gave GhostScript problems for years. The trick is documented in Program 15 page 193 of the awesome PostScript "Blue Book", and it uses a lot of memory! It's one of the coolest tricky PostScript hacks I've ever seen!)
>This program demonstrates how to fill an area with a bitmap pattern using the POSTSCRIPT halftone screen machinery. The setscreen operator is intended for halftones and a reasonable default screen is provided by each POSTSCRIPT implementation. It can also be used for repeating patterns but the device dependent nature of the setscreen operator can produce different results on different printers. As a solution to this problem the procedure, ‘‘setuserscreen,’’ is defined to provide a device independent interface to the device dependent setscreen operator.
>IMPLEMENTATION NOTE: Creating low frequency screens (below 60 lines per inch in device space) may require a great deal of memory. On printing devices with limited memory, a limitcheck error occurs when storage is exceeded. To avoid this error, it is best to minimize memory use by specifying a repeating pattern that is a multiple of 16 bits wide (in the device x-direction) and a screen angle of zero
The disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids.
Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time?
I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.
I think I must misunderstand. Are you saying that you upgrade and reboot every production system that you administer to apply each commit to the kernel (branch it's using) essentially immediately?
That doesn't make sense to me for a few reasons, but I struggle to find a different reading that applies "upgrade and reboot on a moment's notice" to the "slipped into mainline linux" scenario. Kindly help me to do so.
No: your posture with respect to having to cycle servers is a super complicated subject and you address it both with process and with architecture (for instance: you can be blasé about things like CopyFail if you don't allow multitenant shared-kernel in your design in the first place). But no matter what process and design you have, if you're hosting sensitive workloads, you always have to be in a position where you can metabolize having to cycle your servers.
It's a category error to talk about a disclosure event like this as something that would destabilize someone's fleet operations. The Linux kernel is fallible. So is the x64 architecture. You already have to be ready to lock things down and reboot (or mitigate) at a moment's notice.
Remember: whatever else grumpy sysadmins have to say about this, Xint are the good guys. Contrast them with the bad guys, who have vulnerabilities just as bad as CopyFail, but aren't disclosing them at all --- you only find out about them when it's discovered they're actively be exploited. There's no patch at all. There isn't even a characterization of how they work, so that you could quickly see what to seccomp. That's the actual threat environment serious Linux shops operate in.
I find it curious to call someone dropping a weaponized root exploit before major distros or even LTS kernel git branches have patches ready "good guys". This could have been handled with much more grace.
Again: I made the actual distinction between bad guys and good guys clear. Good guys don't become bad guys simply because kernel security is an inconvenience to you.
There are more than just good guys and bad guys; in particular, there are also opportunists.
Opportunists are the ones who will sell a 0day to bad guys. Or who will drop a 0day publicly to promote their services. And they’ll fight tooth and nail against any actual legal obligation to engage in responsible and coordinated disclosure, because they make more money without that.
Seems like a classification you just made up to navigate a message board debate: the category that equates commercial vulnerability research for security products and people who sell zero-day vulnerabilities to bad guys.
People who sell zero-day vulnerabilities currently sell to both good guys and bad guys, they’re a third thing (mercenaries). However, that third thing is also bad, just a different kind of bad than what you’re calling “bad guys.”
The people selling weapons to the Taliban aren’t bad in the same way the Taliban are; one is bad for ideological reasons, the other is bad for enabling bad actors, even if they also sell to the good guys.
Whatever the entity you're thinking of that sells exploits/"CNE enablement packages", they're not in the same bucket as entities that find and disclose vulnerabilities.
Sounds like bounties are unnecessary then. The argument I’ve always seen for them is that if they don’t exist and aren’t substantial enough, the research will still happen but the results will go to the highest bidder.
To be fair, once Xint gave the heads up and the kernel team committed a patch, what was Xint supposed to do? Keep asking the kernel security team to backport patches for the LTS kernels?
As soon as a patch is committed, the clock starts ticking, the exploit will be discovered by reverse engineering recent commits. The commit was made on April 1st, Xint disclosed it on the 29th. If the Kernel Security team had wanted to, they had 28 days to backport patches in the LTS branches...
I don’t know if “cool” is the word I’d use, but there isn’t an established “right” way to disclose a vulnerability that you found outside of a contracted security review or other employment/contracting arrangement.
Enumeration of the entire DNS space is not available in general, but it does appear that some TLDs offer complete zone files for legitimate research purposes, see for example https://czds.icann.org/help#zone-files
They were great in the beginning, and then when you issued a few more certs than they liked you were asked to pony up some $$$, and then when you did that and actually "verified" who you were on a personal international phone call, you got a grace, and then issued a few more, they decided they didn't like you so they would randomly reject your renewals close to the expiration date, and then they got bought out by some scummy foreign outfit which apparently caused the entire CA to be de-listed as untrustworthy in all major browsers. Quite the ride.
Also, the only website I've ever encountered that actually used the HTML <keygen> tag.
It's actually a requirement by app store connect to use a modern sdk for uploading binaries, and modern sdk versions will often raise the minimum supported ios version, so this is not always the developer's fault. See for example https://developer.apple.com/news/upcoming-requirements/?id=0...
https://www.deb-multimedia.org/dists/unstable/main/binary-am...
... it says "fast and small AV1 video stream decoder"
... should probably be "AV2" ?