The effects of copyright on abandonware have been discussed pretty widely in other communities. The primary issue is the contracts and right don't simply expire and it's rare for a company to completely shutter (i.e. assets including these copyrights are acquired or given to creditors). Oracle would need to establish that they have providence over the files and code, and that exceptions for Novel and other code were covered by the OpenSolaris rights reviews. I imagine it might cost low hundreds of thousands of dollars to do lawyers being what they are and commercial *nix being such a melting pot of sources. Since there is no conceivable revenue stream and Oracle isn't much for goodwill I am highly skeptical. Sun releasing OpenSolaris when they finally did and under the CDDL was pretty tone deaf to what was going on in the market with Linux, but you have to admire the amount of contract review and legal work that must have taken. Regards, Kevin On Thu, Aug 30, 2018 at 2:34 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:

On Fri, Aug 31, 2018 at 5:36 PM Cág <ca6c(a)bitmessage.ch> wrote: Yikes -- this is like Rolls Royce cutting a deal with GM and produce a new car based on the Chevy Sububuran, painting it, adding a few details and calling it a Silver Ghost. SunOS != is not Solaris ᐧ

On Fri, Aug 31, 2018 at 3:36 PM Cág <ca6c(a)bitmessage.ch> wrote: No. Not even close. SunOS is BSD based (first 4.2 then 4.3 then with some small amount of System V code) with a written from scratch vm. Solaris is sun's do-over based on System V Release 4. It's great leap backwards. It was a huge slap in the face of the old SunOS crew by inept management. The final indignity was SunOS 4.1 being rebranded Solaris 1.0, which was pure marketing... Warner

On Fri, Aug 31, 2018 at 3:59 PM Larry McVoy <lm(a)mcvoy.com> wrote: It's reason #1 why Netflix can't use ZFS: the double copy problem... Warner

Forgot to add: thanks for the good read, Larry! -- caóc

Jon Forrest wrote: *Open-source BSD distribution. I think it had some license restrictions when the Jolitzes made the 386 port, so they had to put an alternative. Then it was Elvis, nvi was written later on. -- caóc

On 8/31/2018 5:58 PM, Larry McVoy wrote: I would be very interested in anyone's recollections of how Solaris eventually turned out performance-wise, say version 9+, compared to other operating systems. SunOS, Linux, AIX, etc. I find it's about equal, and even exceeds Linux in terms of it's NUMA support and multi-processor support. I need to move some systems away from Solaris and off to Linux, and I find it's NUMA support lacking in certain ways. ak

On Fri, Aug 31, 2018 at 06:57:41PM -0700, Larry McVoy wrote: It wouldn't surprise me if Solaris was more scalable for gazillion dollar SMP machines with a huge number of cores. That was one of the reason as I recall why Solaris had a reputation of being slow; being scalable to big (and much more profitable) servers was considered more important than the smaller systems that were probably more numerous (but not nearly as profitable). - Ted

On Fri, Aug 31, 2018 at 4:02 PM, Arthur Krewat <krewat(a)kilonet.net> wrote: Linux started pulling away fast even on high end systems by the early 2000s. IBM and SGI dumped a ton of money, knowledge, and talent into this. By Linux kernel 2.6 the race was entirely won. After this HP-UX, AIX, and Solaris persist mainly in mainframe-like vertical stacks used mainly to host mission critical applications that are sold in bundles or "solutions" This is pure fantasy. To understand Linux performance on high core count and multi-socket machines is to have at least passing knowledge of Paul McKenney's genius work on RCU [1] and NUMA [2] at Sequent [3] and on Linux. IBM bought Sequent, made a favorable patent grant of RCU for Linux, and the rest history. There is a single feature I have seen in Solaris NUMA that should be implemented elsewhere. It does a micro-benchmark on boot to figure out the inter-core latency map. On stupid technology like Intel's ACPI and Xeon Cluster-on-Die and Sub-NUMA-Clustering, you get bogus data back in the SRAT table describing where the cores are on the on chip network it just chops things in half and doesn't reflect where the cores actually were fused off for yield or binning reasons which is statistically almost always asymmetric. On better engineered technology like IBM's POWER8/9 and OPAL firmware, you get the real locality information of where cores and cache groups actually are. Solaris' neat little micro-benchmark would work optimally even on the brain damaged data from Intel. [1] http://www2.rdrop.com/~paulmck/RCU/ [2] http://www2.rdrop.com/~paulmck/scalability/ [3] http://www2.rdrop.com/~paulmck/techreports/stingcacm3.1999.08.04a.pdf Regards, Kevin

On Sat, Sep 01, 2018 at 09:29:31AM -0700, Kevin Bowling wrote: I think the SPARC bias was very apparent. Sun loved their own chips, to their detriment IMO. I have no personal knowledge of the x86_64 efforts, but I do know about the Sun i386 efforts. That was very looked down upon by the powers that were, the main kernel group, etc. Those poor guys had an uphill battle to get anything integrated, nobody wanted it. So it would not surprise me in the slightest if the x86_64 was a half assed effort without a lot of attention to stuff like performance. I don't think they wanted Solaris/x86 to be a success, they wanted SPARC to be a success. It was that kind of attitude that has pissed me off at every company I have ever worked for. I'm fine with marketing to customers but I hate it when people believe their own marketing. Internally, I think you should be very skeptical, judgemental, critical, whatever you want to call it, if your code sucks or your hardware sucks, don't pretend it doesn't, own it and fix it. That's how you win. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

below... On Sat, Sep 1, 2018 at 12:35 PM Larry McVoy <lm(a)mcvoy.com> wrote: Amen.... ᐧ

On Sat, Sep 1, 2018 at 3:19 PM, Theodore Y. Ts'o <tytso(a)mit.edu> wrote: Sorry this is just bogus about being weak compared to Solaris. Are you looking back with rosy glasses or have you scanned the code in the past couple years? I have and there is nothing particularly special about Solaris internals here or elsewhere. In fact, there are a lot of pessimization all over the place. As Larry said, a lot of folks in the Linux community clearly cared about performance. Although the Solaris code is fairly clean It's not clear Sun valued performance at all. A stroll through arch/*/include/asm/ was enough to convince me of Larry's claims. I'm not a Linux fanboy but credit goes where it's due. Solaris has lgroups, which are a clean design but that is the extent of its NUMA support, one shot at placement and scheduling. Linux has a NUMA allocator, aware scheduler, NUMA-optimized spinlocks and mutexes, various subsystems correctly use the primitives, and can use cgroups to contain or gang things. There is a userland policy tool called numad that tries to add some additional runtime affinity and movement policy decisions. I agree that architecturally Linux NUMA is nowhere near where Sequent and especially SGI was. And the reasons you cite are valid, Linux implementation is good for maybe 8-16 sockets of modern core count with a much tighter off chip network than the big dogs were building. Keep in mind IBM wants to sell RockHoppers and E980s (4 drawers, 16 sockets, 768 threads) for dedicated Linux use which have similar north/south and east/west off chip networks. They have a lot of very talented people on the firmware, kernel, compilers to make these things work fast, including Paul. Windows' NUMA support is on par with Solaris insofar as there is domain aware memory allocator and scheduler hierarchy that takes the domain (and SMT etc) into account. What Windows lacks is the finely tuned concurrency primitives and everything else Linux has done.. which Solaris lacks as well. I'm not even talking about RCU (or epoch based reclamation or proxy collection or hazard pointers, at least one of which is not patent encumbered), I'm just talking about the quality of primitives like spinlocks and mutex and rwlock. There are big tradeoffs to the implementations of these in terms of fairness, progress guarantees, and thread scalability. Linux leads the pack by a long shot in this department. Where you start going beyond Linux-like NUMA IMO is when you get Irix-like features of page copying, migration, and multiple advanced placement policies. Agreed, this is why x86 has dominated the server market for a long time. Agreed. Those big margins must have caused them to take their eye off what mattered right at the time Linux was getting some momentum from the big HW vendors. The E10k was only a 64-core machine on a tight backplane compared to other large systems. It didn't have any of the pressing needs that Sequent and SGI did with multi-drawer interconnects to drive excellence in NUMA. These are strange times. Intel's been putting out some real doozy chips. The mesh in Skylake is a partial improvement over the dual rings of Haswell (though they did some goofy things to increase latency in undesirable ways), and they aren't going to continue to brute force it like IBM did with their 17 metal layer process node.. many SKUs in Cascade Lake will be a dual die design and cost a hilarious amount of money. AMD's EPYC is really bad in this department too, one EPYC behaves identically to a 4 socket system with extremely poor inter-die latency [1]. I think POWER9 is universally better and the high bin chips (22 core, 88 thread, mega cache) are only around $2500 compared to Skylake's absurd $12,000. POWER9 is a single on chip NUMA domain for 24 cores. Google publicly stated they are using it for GPU servers, and that all their monorepo is built for multiple ISAs. Through the grapevine I've heard gmail is running on POWER9 as well now. That is pretty competent, the reason Intel is sucking so bad is because people allowed themselves such lock in. A hyperscaler should be able to change between a couple ISAs as needed between purchasing cycles. True. There is also at least one unencumbered strategy such as epoch based reclamation which was known about around that time [2] [1] https://www.servethehome.com/amd-epyc-infinity-fabric-latency-ddr4-2400-v-2… [2] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf Regards, Kevin

On Sun, Sep 2, 2018 at 12:43 PM, Theodore Y. Ts'o <tytso(a)mit.edu> wrote: One would hope so, but that was the strategy that got them eaten by a grue. Another funny anecdote about this aloofness.. Linux on sparc64 uses the Relaxed Memory Order mode that the hardware offers . Solaris.. Total Store Order. There are tons of things like this in the code that blow my mind. I would have been pissed if I were on the hardware side of SPARC. Hmm, I think they've been pretty earnest at wanting to be 2+ years ahead of the general market with POWER for as long as I can see, lots of HPC money has been subsidizing that. Depends on the workload but bus and memory bandwidth right now with PCIe Gen4 and NvLink can really cut down on server sprawl. I've met with the GM/chief architect and they see OpenPOWER positioned as a full frontal competitor to Intel Xeon. I'm fairly disappointed in my contemporaries for not recognizing the value of a completely open source firmware and on chip controller stack; especially after the recent snafu where Intel changed the microcode license to disallow benchmarks and claimed it was an accident. Your statements make sense to me with respect to AIX, as Linux has been the main effort since the 2000s. GPFS looks neat, I wish it were open or at least internals documented well enough to study the implementation academically. That's probably the dirty little secret. It's long been profitable to carefully plan software interrupt handlers, user threads, and memory allocation even on pedestrian servers if they are running a fixed function. I guess Google's Borg and the new workalikes could do semi-automagic things with cgroups these days. There is evidence of people getting pretty crazy with it when we see things like Intel cache allocation features. Agreed, one of these companies is doing pretty well with a fat dividend yield, that other has basically been dismantled for all but a couple remaining desirable platform control points like Java and MySQL. Many things in tech are happy accidents and a small number of motivated people at the right place and time. A Sun engineer admitted on some video I've seen that the green light was really given for ZFS because they got stumped by some UFS bugs.. once enough of ZFS was written to test the end to end checksumming features they found out some of these heisenbugs were LSI HBA and disk firmware issues :o) Surveying some of these filesystems.. JFS2 is a decent, nowhere near the capabilities of ZFS but even today it's not in dire need of replacement.. I suspect another issue complementary to your point is the standalone storage business is many $B of revenue. ESS/DS8000 and the like are preferred revenue. IBM and HP were more in the SAN game than Sun and SGI who let the customers configure systems themselves be used as storage (Sun was using VxFS for a long time, SGI had some CXFS things IIRC). Tru64 had a pretty interesting filesystem on paper, curious if you ever looked at its design since they open sourced it. Regards, Kevin

On Tue, Sep 4, 2018, 13:40 Gilles Gravier <gilles(a)gravier.org> wrote: I feel like we've been through this before on this list, but perhaps it bears repeating: just because you can find source (or binaries, or CD images, etc.) on the internet, that doesn't make it the least bit legal. That is clearly the case here. Sadly, there are even higher profile sites like the Internet Archive that have this problem too. The concept of "abandonware" has no legal footing whatsoever. -Henry

(Henri, you're in copy of this again, because first time I did a Reply instead of Reply to list/all. Sorry.) Le mar. 4 sept. 2018 à 19:45, Henry Bent &lt;henry.r.bent(a)gmail.com&gt; a écrit : Oh I definitely know the sources aren't officially accessible. By the way, I had copies of them (my QIC tape) when I was a student. I still have the QIC. It's the common example that I use to tell people that opensourcing software makes it more secure because the good guys have access to the source code at the same time as the bad guys, which gives them a fair chance to fix bugs before the bad guys use them. With closed source (SunOS, VMS...) the good guys don't have access to the source code... but the bad guys will always (either by paying somebody enough to make a copy for them, or by finding them on some non legitimate place). As a student I had the source of SunOS (4.1.3) but also VMS (on a few TK-50 tapes). For me, that vetusware site is certainly not legitimate... but since I have the QIC tape at home, I just used it as an easy alternative to having to get the hardware to read my tape back in working order... I certainly do not consider it a legally approved way of distributing code which is, as we all agree, NOT open source. Gilles -- *Gilles Gravier* - Gilles(a)Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 <http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index>

On Wed, Sep 5, 2018 at 6:55 AM Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote: I'm not sure it does. It proves that bugs aren't instantly found, true. It doesn't provide perfection, but does make it easier to find / fix bugs before the bad guys. How long would such a bug have languished it if were buried inside of DCL.B32 instead of being out in the open? Warner

On 9/5/2018 11:26 AM, Warner Losh wrote: It depends on how it was found in the first place. A quick Google doesn't tell me much about exactly how it was discovered initially. Nor is there any background information that says it wasn't (or was) exploited before the announcement. Was it discovered because someone (Stéphane Chazelas) was just reading open source code? Or was he trying to do something innocent and it broke in such a way that it was obvious bash was doing something bad? Or was he investigating a break-in and found the vector? Serious questions, I'd love to hear from anyone who knows more. My original point remains: Open Source doesn't necessarily mean more secure if a really bad exploit was allowed to exist for 25 years. No offense intended to anyone on this list. ak

On Thursday, 6 September 2018 at 9:40:30 +1000, Dave Horsfall wrote: That's a matter of opinion. Many people consider it good manners to specifically mention people participating in a discussion. For example, https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-questions/arti… specifically states: Unless there is a good reason to do otherwise, reply to the sender and to FreeBSD-questions [the list]. That's what procmail is for. Yes, that's in that URL too: Put your response in the correct place (after the text to which it replies). It is very difficult to read a thread of responses where each reply comes before the text to which it replies. Also another thing that I still think very important: If the submitter did not abide by format conventions (lines too long, inappropriate subject line), please fix it. In the case of an incorrect subject line (such as “HELP!!??”), change the subject line to (say) “Re: Difficulties with sync PPP (was: HELP!!??)”. That way other people trying to follow the thread will have less difficulty following it. That doesn't explicitly address the issue of change of topic within a thread, but it should. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA