* [TUHS] unix "awesome list" @ 2018-05-07 18:22 A. P. Garcia 2018-05-07 21:10 ` Dave Horsfall 2018-05-07 22:34 ` Andy Kosela 0 siblings, 2 replies; 29+ messages in thread From: A. P. Garcia @ 2018-05-07 18:22 UTC (permalink / raw) Hi, There's a unix "awesome list". It mentions TUHS's wiki, as well as this quote: "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." - Douglas McIlroy, former head of Bell Labs Computing Sciences Research Center https://github.com/sirredbeard/Awesome-UNIX ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-07 18:22 [TUHS] unix "awesome list" A. P. Garcia @ 2018-05-07 21:10 ` Dave Horsfall 2018-05-07 21:53 ` Steve Johnson 2018-05-07 21:54 ` Steve Nickolas 2018-05-07 22:34 ` Andy Kosela 1 sibling, 2 replies; 29+ messages in thread From: Dave Horsfall @ 2018-05-07 21:10 UTC (permalink / raw) On Mon, 7 May 2018, A. P. Garcia wrote: > "This is the Unix philosophy: Write programs that do one thing and do it > well. Write programs to work together. Write programs to handle text > streams, because that is a universal interface." - Douglas McIlroy, > former head of Bell Labs Computing Sciences Research Center > > https://github.com/sirredbeard/Awesome-UNIX Sadly, Penguin/OS appears to have forgotten this, as it becomes more like Windoze every day... -- Dave ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-07 21:10 ` Dave Horsfall @ 2018-05-07 21:53 ` Steve Johnson 2018-05-08 12:24 ` Theodore Y. Ts'o 2018-05-07 21:54 ` Steve Nickolas 1 sibling, 1 reply; 29+ messages in thread From: Steve Johnson @ 2018-05-07 21:53 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1598 bytes --] Some would argue that it was well on its way to being forgotten by BSD. The problem with that statement is that the deployment of mice and touchscreens meant that the base premise (universal interface) was no longer true. Fonts and markup completed the job. When I first used Unix, I wrote several ed scripts every day, and several shell scripts each week. Glass terminals made ed scripts obsolete without any similar abstraction being available for doing similar text operations on several related files. I still write shell scripts from time to time, but I always feel a little guilty that I'm not writing a simple GUI that would be much clearer and easier to use, but take an order of magnitude longer to write... Steve ----- Original Message ----- From: "Dave Horsfall" <dave@horsfall.org> To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org> Cc: Sent:Tue, 8 May 2018 07:10:55 +1000 (EST) Subject:Re: [TUHS] unix "awesome list" On Mon, 7 May 2018, A. P. Garcia wrote: > "This is the Unix philosophy: Write programs that do one thing and do it > well. Write programs to work together. Write programs to handle text > streams, because that is a universal interface." - Douglas McIlroy, > former head of Bell Labs Computing Sciences Research Center > > https://github.com/sirredbeard/Awesome-UNIX Sadly, Penguin/OS appears to have forgotten this, as it becomes more like Windoze every day... -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180507/a55e4950/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-07 21:53 ` Steve Johnson @ 2018-05-08 12:24 ` Theodore Y. Ts'o 2018-05-08 13:51 ` Bakul Shah 2018-05-08 16:31 ` Michael Parson 0 siblings, 2 replies; 29+ messages in thread From: Theodore Y. Ts'o @ 2018-05-08 12:24 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2233 bytes --] On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote: > Some would argue that it was well on its way to being forgotten by > BSD. The problem with that statement is that the deployment of mice > and touchscreens meant that the base premise (universal interface) was > no longer true. Fonts and markup completed the job. > > When I first used Unix, I wrote several ed scripts every day, and > several shell scripts each week. Glass terminals made ed scripts > obsolete without any similar abstraction being available for doing > similar text operations on several related files. While true, that's only part of the story. There was also the issue that what users wanted to *do* with computers got more complex. Consider spreadsheets and relational databases --- how do they get implemented in "the Unix way"? There was rdb, but it was a bit of a disaster from a performance perspective and only worked for toy databases. And this wasn't unique to Unix. In the VMS world, ALL-IN-1 offered group scheduling/calendaring and other "office software" features. You *could* implemnt a group scheduling system using sed, awk, grep, cat, and pipelines --- but would you want to? Is that the best way to go about doing things? And on the hardware side, the advent of hot-pluggable hardware devices and much more complex UI devices (sound, video cameras, etc.) that need to be made accessible to the logged-in user sitting in front of a particular console, put a lot more pressure on the simple login and /dev model of historical Unix. So sure, it's easy to criticize "PenguinOS" for departing from the Unix ideal. But what's the alternative? Can the criticis design something better that matches the needs and requirements of the users (who don't like big question marks on dashboards as "user friendly" error reporting) and the realities of modern hardware and modern user interface? And if so, would those critics care to implement it and contribute it under a BSD-style license? (Or some other Open Source License)? After all competing with the user friendliness of GNOME should be that hard --- and it's been getting easier over the years as GNOME cuts feature after feature from their system. :-) - Ted ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 12:24 ` Theodore Y. Ts'o @ 2018-05-08 13:51 ` Bakul Shah 2018-05-08 14:53 ` Clem Cole 2018-05-08 16:31 ` Michael Parson 1 sibling, 1 reply; 29+ messages in thread From: Bakul Shah @ 2018-05-08 13:51 UTC (permalink / raw) On Tue, 08 May 2018 08:24:29 -0400 "Theodore Y. Ts'o" <tytso at mit.edu> wrote: Theodore Y. Ts'o writes: > On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote: > > Some would argue that it was well on its way to being forgotten by > > BSD. The problem with that statement is that the deployment of mice > > and touchscreens meant that the base premise (universal interface) was > > no longer true. Fonts and markup completed the job. > > > > When I first used Unix, I wrote several ed scripts every day, and > > several shell scripts each week. Glass terminals made ed scripts > > obsolete without any similar abstraction being available for doing > > similar text operations on several related files. > > While true, that's only part of the story. There was also the issue > that what users wanted to *do* with computers got more complex. > Consider spreadsheets and relational databases --- how do they get > implemented in "the Unix way"? There was rdb, but it was a bit of a > disaster from a performance perspective and only worked for toy > databases. And this wasn't unique to Unix. In the VMS world, > ALL-IN-1 offered group scheduling/calendaring and other "office > software" features. You *could* implemnt a group scheduling system > using sed, awk, grep, cat, and pipelines --- but would you want to? > Is that the best way to go about doing things? > > And on the hardware side, the advent of hot-pluggable hardware devices > and much more complex UI devices (sound, video cameras, etc.) that > need to be made accessible to the logged-in user sitting in front of a > particular console, put a lot more pressure on the simple login and > /dev model of historical Unix. > > So sure, it's easy to criticize "PenguinOS" for departing from the > Unix ideal. But what's the alternative? Can the criticis design > something better that matches the needs and requirements of the users > (who don't like big question marks on dashboards as "user friendly" > error reporting) and the realities of modern hardware and modern user > interface? > > And if so, would those critics care to implement it and contribute it > under a BSD-style license? (Or some other Open Source License)? > After all competing with the user friendliness of GNOME should be that > hard --- and it's been getting easier over the years as GNOME cuts > feature after feature from their system. :-) > > - Ted Great response! Agree with a lot of this (except GNOME!). Shell was a good glue language in that it allowed easy composition of programs that fit its model from simpler programs. A similar model exists for services composed from microservices but now the 'pipes' are often not unidirectional or simple lines of text. And dynamic scaling is required. etc. But we do not have a similar easy to use glue language. Graphical interfaces get used but except in special fields they are not compositional. Graphical languages remained researchy. in other areas existing solutions are rejected as being not efficient enough or hard to integrate in the unix model. Example: capabilities. Unix file descriptors are in fact capabilities but they are still file/dir/device or socket descriptors, mainly confined to individual processes. Experiments in pure capability based OSes havent gone far. In FreeBSD we have capsicum but that has added complexity, not removed it. And we are still writing concurrent programs using mutexes. No practical progress in 40 years. If you think about it, most all the new things added in last 3 decades haven't had the cohesion of design like the original unix design. And yet, I think extending the unix model is quite possible. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 13:51 ` Bakul Shah @ 2018-05-08 14:53 ` Clem Cole 2018-05-08 15:23 ` Jon Steinhart ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Clem Cole @ 2018-05-08 14:53 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 5521 bytes --] I'll take a slight different road on this topic. I think we are dealing with the paradox of progress. I don't blame Linux's developers any more than I blame BSDs or anyone else. Really it was hardware progress/Moore's law that changed the rules :-) As much as I wax a bit for the simplicity of the Fifth, Sixth, and Seventh Editions of my youth, the truth is I would not want to try to use them today. My needs are now different and I think the is true for most people also which is why a modern UNIX implementation is different from the original ideas or maybe I should say ideal. That said, a lot of what I did then, ands like Steve, I still do use and many of the 'classic solutions' I find are better for me (*i.e. *troff *vs.* MS-Word) Pike's '*cat -v harmfu*l' paper foretold where we would get. On the PDP-11 with a limited address, a programmer was constrained so you had to keep things simple. The programming model of small simple programs that did one thing well, was easier to 'enforce.' The ideas that formed UNIX make sense, and yoiu could build an extremely power 'system' from simple and small things. At the time, that was almost heretical. But once HW dropped in price and the address space issues relaxed the size of a program that could be written, people did. The cast was out of the bag, and there was no going back. I'm not saying all of the new BSDism of the time were right, but they certainly made many things easier/more approachable for many users and many/most live in modern UNIX definition. I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit. Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them. But .... slowly the system changed and the *expectations* of the users with them. I admit, I'm torn. I do think Pike was right and many of the new features/frameworks *et al* are pretty lame (useless IMHO) and the simpler/cleaner methods of old, are being ignored. Dave Pressotto and I were talking a week or so ago and Dave made the observation that he's not sure he knows how write a modern program now with all these frameworks, IDEs, *etc* and I completely agree. But that is the old guy in me talking; but I really do want to see progress and the new generation make its mark. I'm sure they will do wonderful things. Bakul's observation of little >>practical<< progress is an interesting one. In many ways I agree, in others I'm not so sure. I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (*i.e.* the whole systemd argument). But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis. For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread). I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed). it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear. But I don't want it re-implement UNIX or Linux. Grab from them the subsystems that you need to duplication, but don't re-invent. Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple. We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas. I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated. I like progress we have now. I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work. Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards. The problem is how to decide what was good and what was bad? What is real progress and what is just 'showing off your money' to use a Forest Gump concept. I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/00c6ae79/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 14:53 ` Clem Cole @ 2018-05-08 15:23 ` Jon Steinhart 2018-05-08 15:31 ` Steve Johnson 2018-05-08 21:15 ` [TUHS] unix "awesome list" Bakul Shah 2 siblings, 0 replies; 29+ messages in thread From: Jon Steinhart @ 2018-05-08 15:23 UTC (permalink / raw) Here's an excerpt from the book on which I'm working (thanks to Clem for proofreading) that is my take on how things got to be the way that they are today. BTW, I was coming into work one evening when Ken was heading out the door for his sabbatical. I remember him just waltzing past the security guard with an armload of mag tapes and thinking wow, there aren't that many people who could get away with that. Jon A long time ago people made money selling computers. Software was written and given away in order to help sell computers. There was a culture of sharing and working together to improve software. More and more people wrote and shared software as computers became more accessible. The Multics operating system was collaboratively developed in the 1960s by Bell Telephone Laboratories, General Electric, and the Massachusetts Institute of Technology. Bell pulled out of the project, and some of the people (most notably Ken Thompson and Dennis Ritchie) there who had worked on it decided to make a more practical version that ran on the smaller minicomputers produced by the Digital Equipment Corporation (DEC). It was the first portable operating system which means that it could run on more than one type of computer. This innovative operating system, UNIX, embodied a new minimalist and modular philosophy for software that we'll discuss shortly. Ken Thompson took a copy of UNIX with him in 1975 when he took a sabbatical year to teach at the University of California, Berkeley. This had a huge effect that still reverberates today. Students had access to a real working system. They could examine the code to see how things worked, and they could make changes. Not only that, but they were exposed to the philosophy. Berkeley produced its own version of UNIX, BSD for Berkeley SPoftware Distribution. Students added many new important features to the system. The networking code that is the foundation of the Internet was written for UNIX at Berkeley. Berkeley graduates started companies such as Sun Microsystems that made commercial UNIX-based systems. Personal computers changed this. All of a sudden the people writing software weren't the people selling computers, so they needed to charge for it. But there was still an attitude of ``it's great that we make a living doing this cool stuff''. This changed dramatically when Bill Gates came on the scene. As is evident from numerous court depositions, his focus was on making money. If he had to do something cool to make money he would, but his priorities were opposite those of others in the industry. How did this change things? Software development began to be driven more by politics, lawyers, and underhanded behavior than engineers. Much of this focused on suppressing innovation that competed with existing products. For example, Microsoft started with MS-DOS, a program that they bought from its developer Tim Paterson. Microsoft let it languish as they were making plenty of money from it. A company called Digital Research came out with an improved version called DR-DOS. When Microsoft came out with Windows, the original version of which ran on top of DOS, they included a hidden, encrypted piece of code that checked to see if the system was running MS-DOS or DR-DOS, and generated phony errors if it found DR-DOS. This made DR-DOS unsuccessful in the marketplace even though it was a arguably better product for the money. It wasn't just Microsoft. Apple also sued Digital Research for copying their user interface in a product called GEM. Digital Research would probably have prevailed eventually, but would have gone bankrupt in the process because Apple had much deeper pockets. Somewhat absurd when you realize that the Apple user interface was substantially copied from the Xerox Alto. Unfortunately, this mindset continues today with threatened big players resorting to the courts instead of innovating their way out of their difficulties. Examples abound such as SCO versus IBM, Oracle versus Google, Apple versus Samsung, Samsung versus Apple, Intellectual Ventures shell companies versus the world, etc. Personal computers started becoming popular in the mid-1980s. It wasn't practical to run UNIX on them because the hardware lacked a memory management unit although there was a variant called Xenix that did run on PCs. Colleges starting using personal computers to teach computer science because they were cheaper. However, unlike the UNIX-era graduates from Berkeley, students did not have the ability to look at the code of the system that they were using. And the system with which they became familiar was considerably less advanced than UNIX. As a result graduates from this era were not generally of the same quality. In part as a reaction to this, Richard Stallman started the GNU (Gnu's Not Unix) project in 1983. Among other things, the goal was to create a free, open-source version of UNIX. Stallman created the copyleft, a variant of the copyright used by others to protect their software. The copyleft essentially said that others were free to use and modify the code as long as they made their modifications available under the same terms. In other words, we'll share our code with you if you share yours with everyone else. The GNU project did a great job of recreating the UNIX utilities such as cp. But it was slow to create the operating system itself. Linus Torvaldis began work on what is now known as the Linux operating system in 1991 because there was no GNU operating system. To a large degree this work was made possible by the existence of the GNU tools such as the C compiler. Linux has become extremely popular. It's used heavily in data centers (the cloud), it's the underlying software in Android devices, it's in many appliances. This book was written on a Linux system. Large companies were originally skeptical about using open source software. Who would fix the bugs? Somewhat ludicrous; if you've ever reported a bug to Microsoft, Apple, or any other large company you know how much attention it gets. In 1989, John Gilmore, David Henkel-Wallace, and Michael Tiemann founded Cygnus Support to provide commercial support for open source software. It's existence greatly increased the willingness of companies to use open source software. In many ways Linux and GNU have brought us a new golden era similar to the Berkeley UNIX days. It's not quite as shiny because some of the people from the PC era are making changes without really understanding the philosophy. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 14:53 ` Clem Cole 2018-05-08 15:23 ` Jon Steinhart @ 2018-05-08 15:31 ` Steve Johnson 2018-05-08 16:32 ` Clem Cole ` (4 more replies) 2018-05-08 21:15 ` [TUHS] unix "awesome list" Bakul Shah 2 siblings, 5 replies; 29+ messages in thread From: Steve Johnson @ 2018-05-08 15:31 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 7369 bytes --] Well, as I look to the future I see the whole approach we have to software running into a dead end. In fact, I think software is holding us back. It wasn't always true. In the old days, software ideas (like floating point, index registers, caches, etc.) proved their worth and were put into hardware to make them faster. I think around 1980 this stopped happening. Instead, hardware gave us 20 years of Moore's law, with ever faster and cheaper processors. The increase in performance pretty much hid the inefficiency that the software bloat introduced. Starting about 2000, this changed. Hardware was no longer offering increased speed. But what it was offering was massive parallelism. The response was to cling to the one instruction at a time model, introducing multicore and its attendant hardware complexity to try to cling to the previous model of programming. The hardware to make this possible is expensive and does not scale. My company, Wave Computing, has built a chip with 16,000 8-bit processors on it. And we have plans to build systems with up to a quarter million processors. We are breaking ground in new ways to use hundreds of processors to solve problems very quickly. It's a new way of thinking, and it makes your brain hurt. But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam. And it's exciting... Steve ----- Original Message ----- From: "Clem Cole" <clemc at ccc.com> To: "Bakul Shah" <bakul at bitblocks.com> Cc: "The Eunuchs Hysterical Society" <tuhs at tuhs.org> Sent: Tue, 8 May 2018 10:53:16 -0400 Subject: Re: [TUHS] unix "awesome list" I'll take a slight different road on this topic. I think we are dealing with the paradox of progress. I don't blame Linux's developers any more than I blame BSDs or anyone else. Really it was hardware progress/Moore's law that changed the rules :-) As much as I wax a bit for the simplicity of the Fifth, Sixth, and Seventh Editions of my youth, the truth is I would not want to try to use them today. My needs are now different and I think the is true for most people also which is why a modern UNIX implementation is different from the original ideas or maybe I should say ideal. That said, a lot of what I did then, ands like Steve, I still do use and many of the 'classic solutions' I find are better for me (_i.e. _troff _vs._ MS-Word) Pike's '_cat -v harmfu_l' paper foretold where we would get. On the PDP-11 with a limited address, a programmer was constrained so you had to keep things simple. The programming model of small simple programs that did one thing well, was easier to 'enforce.' The ideas that formed UNIX make sense, and yoiu could build an extremely power 'system' from simple and small things. At the time, that was almost heretical. But once HW dropped in price and the address space issues relaxed the size of a program that could be written, people did. The cast was out of the bag, and there was no going back. I'm not saying all of the new BSDism of the time were right, but they certainly made many things easier/more approachable for many users and many/most live in modern UNIX definition. I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit. Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them. But .... slowly the system changed and the _expectations_ of the users with them. I admit, I'm torn. I do think Pike was right and many of the new features/frameworks _et al_ are pretty lame (useless IMHO) and the simpler/cleaner methods of old, are being ignored. Dave Pressotto and I were talking a week or so ago and Dave made the observation that he's not sure he knows how write a modern program now with all these frameworks, IDEs, _etc_ and I completely agree. But that is the old guy in me talking; but I really do want to see progress and the new generation make its mark. I'm sure they will do wonderful things. Bakul's observation of little >>practical<< progress is an interesting one. In many ways I agree, in others I'm not so sure. I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (_i.e._ the whole systemd argument). But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis. For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread). I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed). it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear. But I don't want it re-implement UNIX or Linux. Grab from them the subsystems that you need to duplication, but don't re-invent. Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple. We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas. I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 [1] which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated. I like progress we have now. I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work. Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards. The problem is how to decide what was good and what was bad? What is real progress and what is just 'showing off your money' to use a Forest Gump concept. I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not. Clem ᐧ Links: ------ [1] https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/a6959a50/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 15:31 ` Steve Johnson @ 2018-05-08 16:32 ` Clem Cole 2018-05-08 17:33 ` Theodore Y. Ts'o ` (3 subsequent siblings) 4 siblings, 0 replies; 29+ messages in thread From: Clem Cole @ 2018-05-08 16:32 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1824 bytes --] On Tue, May 8, 2018 at 11:31 AM, Steve Johnson <scj at yaccman.com> wrote: > Well, as I look to the future I see the whole approach we have to software > running into a dead end. In fact, I think software is holding us back. > You might be right here, but where we disagree I think is economics. The problem is that we can not afford to replace SW. As I like to point out, Fortran still pays my salary -- why because all the data and codes that use that data written since the late 1950s. Its just worse in the commercial side. Word and Lookout/Exchange sucks - but people use them and they are not going away. Think about the LISP Machine or the CM1 - lots of people though they were 'better' for some concept of goodness. But they failed in the end. > > ... > > Starting about 2000, this changed. Hardware was no longer offering > increased speed. But what it was offering was massive parallelism. The > response was to cling to the one instruction at a time model, introducing > multicore and its attendant hardware complexity to try to cling to the > previous model of programming. The hardware to make this possible is > expensive and does not scale. > I agree but ... IMO its going to take a real Christensen disruption with a new customer base. I just don't see that happening any time soon. Without a new customer base to support the new technology, the economics of the keeping the old running has and will continue to go forward. > > And it's exciting... > I agree and I'm a fan and cheering from the sidelines .... but I'm skeptical of success because the economics don't play to success.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/facfc5f5/attachment-0001.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 15:31 ` Steve Johnson 2018-05-08 16:32 ` Clem Cole @ 2018-05-08 17:33 ` Theodore Y. Ts'o 2018-05-08 18:40 ` William Cheswick ` (2 subsequent siblings) 4 siblings, 0 replies; 29+ messages in thread From: Theodore Y. Ts'o @ 2018-05-08 17:33 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3279 bytes --] On Tue, May 08, 2018 at 08:31:43AM -0700, Steve Johnson wrote: > Well, as I look to the future I see the whole approach we have to > software running into a dead end. In fact, I think software is > holding us back. What's holding us back is our human minds' ability to manage complexity. > Starting about 2000, this changed. Hardware was no longer offering > increased speed. But what it was offering was massive parallelism. > The response was to cling to the one instruction at a time model, > introducing multicore and its attendant hardware complexity to try to > cling to the previous model of programming. The hardware to make > this possible is expensive and does not scale. > > My company, Wave Computing, has built a chip with 16,000 8-bit > processors on it. And we have plans to build systems with up to a > quarter million processors. We are breaking ground in new ways to > use hundreds of processors to solve problems very quickly. It's a > new way of thinking, and it makes your brain hurt. And that's the problem. If we can't program the new machines, whether it's Sun's attempt at large number of weak cores with their Niagra chips, or your company's vast number of 8-bit processors --- as the old saying goes, without software, it's just a doorstop. Moving the discussion back to Unix, the problem is that we don't have a lot of solutions to the complexity wall. The most common one seems to be deny the existence, or the validity of the requiremnts. (e.g., "Teach them all English; if 7-bit ASCII was good enough for K&R, it's good enough for me." or "Text files are all you need; why do you need new-fangled things like group calendaring or spreadsheets"?) Or you can just build on top of pre-existing systems, but then you get complaints about kludge towers and overly complex systems. Or you can give up on generality, and build a bespoke system that only addresses the problem you are paid to solve. Which may or may not be cheaper than using the more general solution and brute-forcing the problem by throwing more hardware on it, on the theory that hardware is cheaper than software engineering skills. > ... In the old days, software ideas (like floating point, index > registers, caches, etc.) proved their worth and were put into > hardware to make them faster. I think around 1980 this stopped > happening. This is not strictly true. A counter-example would be Google's Tensor Processing Units[1]. That's an example of custome hardware replacing what had previously been doing in pure software, or using more general hardware units (e.g., GPU's). Another example would be AES and SHA-256 acceleration being done in hardware in multiple CPU architectures, and in the data path between the CPU and the eMMC flash on some cell phones. [1] https://techcrunch.com/2017/05/17/google-announces-second-generation-of-tensor-processing-unit-chips/ I think it is true we have hit the point of diminishing returns, in that as software gets more complex, finding things which are commonly used enough, and which have enough of a benefit that it is worth the engineering effort and cost of moving that functionality into hardware is much harder now compared to a few decades ago. - Ted ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 15:31 ` Steve Johnson 2018-05-08 16:32 ` Clem Cole 2018-05-08 17:33 ` Theodore Y. Ts'o @ 2018-05-08 18:40 ` William Cheswick 2018-05-08 21:25 ` Bakul Shah 2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg 4 siblings, 0 replies; 29+ messages in thread From: William Cheswick @ 2018-05-08 18:40 UTC (permalink / raw) It is amazing how well pipes fit into this model, up to a point. I once wrote a program to generate and collate hundreds of thousands of images. I used the sed/grep/awk model, with all the ease of attendant text I/O processing. I was surprised one day to find it running twice as fast as usual. They had doubled the number of CPUs in the machine, and my program Just Worked. Not bad for an idea that was 35 years old. Of course, your fleet of processors will require different programming (CSP with go?). I look forward to see if your solutions are even remotely as easy and useful as the originals. BTW, will those processors basically be 8051s? ches > On 8May 2018, at 11:31 AM, Steve Johnson <scj at yaccman.com> wrote: > > My company, Wave Computing, has built a chip with 16,000 8-bit processors on it. And we have plans to build systems with up to a quarter million processors. We are breaking ground in new ways to use hundreds of processors to solve problems very quickly. It's a new way of thinking, and it makes your brain hurt. But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam. > > And it's exciting... > > Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/8ca0a25e/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 15:31 ` Steve Johnson ` (2 preceding siblings ...) 2018-05-08 18:40 ` William Cheswick @ 2018-05-08 21:25 ` Bakul Shah 2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg 4 siblings, 0 replies; 29+ messages in thread From: Bakul Shah @ 2018-05-08 21:25 UTC (permalink / raw) On May 8, 2018, at 8:31 AM, Steve Johnson <scj at yaccman.com> wrote: > > My company, Wave Computing, has built a chip with 16,000 8-bit processors on it. And we have plans to build systems with up to a quarter million processors. We are breaking ground in new ways to use hundreds of processors to solve problems very quickly. It's a new way of thinking, and it makes your brain hurt. But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam. This sounds like a software equivalent of an FPGA! You probably have similar to "EDA" tools for placement and routing and mapping a program written in "HDL" to the underlying technology. Mapping APL to this could be fun (APL programs have a similar brain hurting side-effect!). Somewhat relevant: A retrospective on 30 years of FPGA technology: https://ieeexplore.ieee.org/document/7086413/#full-text-section ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") 2018-05-08 15:31 ` Steve Johnson ` (3 preceding siblings ...) 2018-05-08 21:25 ` Bakul Shah @ 2018-05-08 23:06 ` Lyndon Nerenberg 2018-05-09 0:25 ` Ron Natalie 4 siblings, 1 reply; 29+ messages in thread From: Lyndon Nerenberg @ 2018-05-08 23:06 UTC (permalink / raw) > On May 8, 2018, at 8:31 AM, Steve Johnson <scj at yaccman.com> wrote: > > My company, Wave Computing, has built a chip with 16,000 8-bit processors on it. And we have plans to build systems with up to a quarter million processors. We are breaking ground in new ways to use hundreds of processors to solve problems very quickly. It's a new way of thinking, and it makes your brain hurt. But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam. This might be going a bit out-of-bounds for the mailing list, but ... How does what you are doing compare with the work the Myrias folks were doing in the mid-late 1980s with their n-way 680x0(?) parallel machines? Didn't they make it to 256 processors before it collapsed? I'm not aware of any papers that came out of their work, although I would think there must have been at least a few. (Dan Wilson, are you on this mailing list?) I didn't have the opportunity to see what Myrias was putting together as their OS. But I did get to play with an indirect off-shoot of their work: a massive scale (for the time) file server, based on some of that parallel processing technology. It mimicked the Plan9 Venti in some ways. It was very block-oriented in its external API, and I used that lowish-level API to write a backend file store for the big-a** IMAP servers we were developing at the time. I'm sure it would have kicked NetApp and friends around the block, but this was the late 1990s, and we were limited by 100 Mb/s Ethernet, so there was no real way to tell. --lyndon ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") 2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg @ 2018-05-09 0:25 ` Ron Natalie 2018-05-09 1:28 ` Kurt H Maier 0 siblings, 1 reply; 29+ messages in thread From: Ron Natalie @ 2018-05-09 0:25 UTC (permalink / raw) BRL had contracted with the Denver Electronics Corporation (Denelcor) to build a fluid dynamic platform. Early plans were for an analog and then hybrid computer, but this quickly evolved into the all-digital Heterogenous Element Procesor. The computer was MIMD and could run 40 or so threads simultaneously while hardware scheduling 256 times that. Each memory location in the main memory had a "full-empty" bit which allowed you to to execute instructions like "Wait until Full, then Store", and the processor handled all that. Of course, this was about the time Mike Muuss and his band were becoming real firecrackers in the labs. Mike shot his mouth off that we could put UNIX on it (our answer to everything) and the lab management took us up on the offer. Perhaps, with the exception of some of the MultibusII stuff, one of the nicest UNIX architectures around. Mike immediately set to work. He did the C compiler while Doug Kingson did the assembler. I did the loader I think. We then started on the kernel. Mike doing the low level stuff and the guts of the kernel and me doing all the IO (the "dmr" directory traditionally). About the time we got the thing running I realized that the IO performance was terrible. The thing had a sidecar unit with 32 distinct unibuses which really should have been fast enough, except the latency to start the I/Os was about ten ops/sec. Me and the HEP designer, Burton Smith sat down at the Golden Corral steakhouse in Aberdeen and designed a new processor that sat on the main memory bus. It was built out of spare HEP parts and a PDP-11/34 that I had lying around as the control processer. I through in the LOS operating system (No time for sharing -- Uniprocessor system) scavenged from my BRL Gateway code to drive it. In two days we had drastically increased the IO performance. The thing ran parallizable apps, notably Mike's BRL ray tracing "CAD" package. We pretty much used it to generate a movie of a shell's eye view of a collision with a tank. The system was replaced with a Cray XMP. Amusingly in our machine room, awaiting arrival of the HEP were taped out markings where all the cabinets went around a central building pillar. Visiting the machine in the factor, it was laid out around a taped marking showing the location of our post. -Ron ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") 2018-05-09 0:25 ` Ron Natalie @ 2018-05-09 1:28 ` Kurt H Maier 0 siblings, 0 replies; 29+ messages in thread From: Kurt H Maier @ 2018-05-09 1:28 UTC (permalink / raw) On Tue, May 08, 2018 at 08:25:08PM -0400, Ron Natalie wrote: > > Of course, this was about the time Mike Muuss and his band were becoming > real firecrackers in the labs. Mike shot his mouth off that we could put > UNIX on it (our answer to everything) and the lab management took us up on > the offer. Perhaps, with the exception of some of the MultibusII stuff, > one of the nicest UNIX architectures around. > A gentleman at ARL during my time there once mentioned they had some "real nice parallel systems" until someone "ruined them with unix"... I never did get details on which system he would have preferred pristine. khm ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 14:53 ` Clem Cole 2018-05-08 15:23 ` Jon Steinhart 2018-05-08 15:31 ` Steve Johnson @ 2018-05-08 21:15 ` Bakul Shah 2 siblings, 0 replies; 29+ messages in thread From: Bakul Shah @ 2018-05-08 21:15 UTC (permalink / raw) On May 8, 2018, at 7:53 AM, Clem Cole <clemc at ccc.com> wrote: > > I'll take a slight different road on this topic. I think we are dealing with the paradox of progress. I don't blame Linux's developers any more than I blame BSDs or anyone else. Really it was hardware progress/Moore's law that changed the rules :-) Agree about the paradox of progress. Success slowed down further evolution. While h/w speed and number of gates increased tremendously the particular *direction* processor architecture took is heavily influenced by prevailing software. So I think it is really software that is to blame :-) Intel did add callgates for better containment but they didn't get used much. > I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit. Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them. But .... slowly the system changed and the expectations of the users with them. The price of success. It is easier to bolt-on solutions to new problems on existing platform than refine the platform. Plan9 tried that. That it failed has more to do with non-tech reasons. > Bakul's observation of little >>practical<< progress is an interesting one. In many ways I agree, in others I'm not so sure. I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (i.e. the whole systemd argument). The lack of progress I am talking about has to do with the devil's bargain of trading simplicity for "efficiency". The 16bit CPU running at 5Mhz, with 256K of RAM and 5MB of disk in 1981 is replaced with a 64 bit processor with 16 cores, 64GB of RAM, with 10TB of disk space, with HDMI screen and 1GB/s network port (and is cheaper in terms of 1981 dollars). And yet we continue making this bargain. Pipes provided a perfect way to modularize programs. But we use shared memory and threads - mainly for squeezing out more performance. We have known about microkernels for over 30 years. CSP for over 40 years. Capability systems for over 50 years. Yet these are largely absent. Even Go provides unsafe shared memory access in spite of providing channels. > But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis. For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread). I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed). Plan9 did a much cleaner job of adding filesystems and networking. May be the 9p protocol doesn't scale so well but that could've been fixed once it was used in production systems. A capability system would obviate the need for containers. If all external communication a process did was via capabilities, it doesn't matter if they directly access some physical device or virtual device, a local server or a remote server, a real file or a synthetic file. Microkernels and caps are a good match. But they too haven't been used enough in practice and will need evolution. > it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear. But I don't want it re-implement UNIX or Linux. Grab from them the subsystems that you need to duplication, but don't re-invent. > > > Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple. We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas. I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated. I like progress we have now. I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work. > > Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards. The problem is how to decide what was good and what was bad? What is real progress and what is just 'showing off your money' to use a Forest Gump concept. > > I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not. I think it is possible to gain equivalent feature comforts using simpler systems. But my guess is "compatibility" requirement is what will hold us back. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 12:24 ` Theodore Y. Ts'o 2018-05-08 13:51 ` Bakul Shah @ 2018-05-08 16:31 ` Michael Parson 2018-05-08 17:20 ` Larry McVoy 2018-05-08 17:53 ` Theodore Y. Ts'o 1 sibling, 2 replies; 29+ messages in thread From: Michael Parson @ 2018-05-08 16:31 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2982 bytes --] On 2018-05-08 07:24, Theodore Y. Ts'o wrote: > On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote: >> Some would argue that it was well on its way to being forgotten by >> BSD. The problem with that statement is that the deployment of mice >> and touchscreens meant that the base premise (universal interface) was >> no longer true. Fonts and markup completed the job. >> >> When I first used Unix, I wrote several ed scripts every day, and >> several shell scripts each week. Glass terminals made ed scripts >> obsolete without any similar abstraction being available for doing >> similar text operations on several related files. > > While true, that's only part of the story. There was also the issue > that what users wanted to *do* with computers got more complex. > Consider spreadsheets and relational databases --- how do they get > implemented in "the Unix way"? There was rdb, but it was a bit of a > disaster from a performance perspective and only worked for toy > databases. And this wasn't unique to Unix. In the VMS world, > ALL-IN-1 offered group scheduling/calendaring and other "office > software" features. You *could* implemnt a group scheduling system > using sed, awk, grep, cat, and pipelines --- but would you want to? > Is that the best way to go about doing things? > > And on the hardware side, the advent of hot-pluggable hardware devices > and much more complex UI devices (sound, video cameras, etc.) that > need to be made accessible to the logged-in user sitting in front of a > particular console, put a lot more pressure on the simple login and > /dev model of historical Unix. > > So sure, it's easy to criticize "PenguinOS" for departing from the > Unix ideal. But what's the alternative? Can the criticis design > something better that matches the needs and requirements of the users > (who don't like big question marks on dashboards as "user friendly" > error reporting) and the realities of modern hardware and modern user > interface? > > And if so, would those critics care to implement it and contribute it > under a BSD-style license? (Or some other Open Source License)? > After all competing with the user friendliness of GNOME should be that > hard --- and it's been getting easier over the years as GNOME cuts > feature after feature from their system. :-) > For me, it's not really the proliferation of servers (rdbms, web servers, collaboration back-ends, etc), desktop apps (spreadsheets, word processors, etc), but more of the 'traditional' unix cli utils that have grown beyond the 'do one thing' mantra. Going beyond 'cat -v considered harmful', things like ifconfig, route, and netstat being considered 'deprecated' and replaced with the 'ip' tool. Same with syslog, cron, init, and who knows what else, being replaced with systemd and journald. This doesn't even cover how vim has become way more than just a GNU re-implementation of vi. -- Michael Parson Pflugerville, TX KF5LGQ ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 16:31 ` Michael Parson @ 2018-05-08 17:20 ` Larry McVoy 2018-05-08 17:49 ` Michael Parson 2018-05-08 20:48 ` Dave Horsfall 2018-05-08 17:53 ` Theodore Y. Ts'o 1 sibling, 2 replies; 29+ messages in thread From: Larry McVoy @ 2018-05-08 17:20 UTC (permalink / raw) On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote: > Going beyond 'cat -v considered harmful', things like ifconfig, route, and > netstat being considered 'deprecated' and replaced with the 'ip' tool. Same > with syslog, cron, init, and who knows what else, being replaced with > systemd and journald. This doesn't even cover how vim has become way more > than just a GNU re-implementation of vi. I'm not thrilled with the systemd stuff either, I still don't see that it is solving anything that wasn't solved. But somebody must like it, it's a big change. vim, on the other hand, oh do I love me some vim. It's pretty faithful to the original vi but you get split windows, infinite undo, it remembers stuff from one invocation to the next, it's pretty sweet. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 17:20 ` Larry McVoy @ 2018-05-08 17:49 ` Michael Parson 2018-05-08 20:48 ` Dave Horsfall 1 sibling, 0 replies; 29+ messages in thread From: Michael Parson @ 2018-05-08 17:49 UTC (permalink / raw) On Tue, 8 May 2018, Larry McVoy wrote: > On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote: >> Going beyond 'cat -v considered harmful', things like ifconfig, >> route, and netstat being considered 'deprecated' and replaced with >> the 'ip' tool. Same with syslog, cron, init, and who knows what >> else, being replaced with systemd and journald. This doesn't even >> cover how vim has become way more than just a GNU re-implementation >> of vi. > > I'm not thrilled with the systemd stuff either, I still don't see that > it is solving anything that wasn't solved. But somebody must like it, > it's a big change. I'm not thrilled with it either, but it seems to be how things are going, so, I've been forced to learn how to use it. > vim, on the other hand, oh do I love me some vim. It's pretty > faithful to the original vi but you get split windows, infinite undo, > it remembers stuff from one invocation to the next, it's pretty sweet. I resisted it for a long time, installed nvi on my penguin boxes so I could have something resembling the vi I was raised on, but I've come to appreciate a few of its features. It just took some time to reprogram my fingers for some of the features. I find 'vimdiff' extremely useful, but it's not really 'the unix way'. :) -- Michael Parson Pflugerville, TX KF5LGQ ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 17:20 ` Larry McVoy 2018-05-08 17:49 ` Michael Parson @ 2018-05-08 20:48 ` Dave Horsfall 1 sibling, 0 replies; 29+ messages in thread From: Dave Horsfall @ 2018-05-08 20:48 UTC (permalink / raw) On Tue, 8 May 2018, Larry McVoy wrote: > vim, on the other hand, oh do I love me some vim. It's pretty faithful > to the original vi but you get split windows, infinite undo, it > remembers stuff from one invocation to the next, it's pretty sweet. Oh, I love VIM too, but I wish it had an "idiot" mode i.e. ignore any fumbled keys that did something strange and how do I get out of here because suddenly I see two windows when I meant to simply quit... -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM) ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 16:31 ` Michael Parson 2018-05-08 17:20 ` Larry McVoy @ 2018-05-08 17:53 ` Theodore Y. Ts'o 1 sibling, 0 replies; 29+ messages in thread From: Theodore Y. Ts'o @ 2018-05-08 17:53 UTC (permalink / raw) On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote: > Going beyond 'cat -v considered harmful', things like ifconfig, route, and > netstat being considered 'deprecated' and replaced with the 'ip' tool. For better or worse, *networking* has gotten much more complicated. So there are many more ways of specfying a routing rule than just a IP subnet, a mask, and a weight. After a while, trying to add new functionality to old interface just simply gets too hard. Again, what's the solution? You can deny the legitimacy of the new features, and the requirements that caused those new featuers to be designed and implemented. Or you can accept that there's going to be a new interface that is designed to be more extensible, and the old interfaces will be maintained for backwards compatibility --- but if you want to do something fancy, you'll need to use the new interfaces. I still often used ifconfig myself, truth be told. But there are times when I will use the new interfaces, because I need to use the new features. As far as the question of using a multiplexed command --- e.g., "ip route" versus "route", "ip link" versus ifconfig, that's really more of a sylistic change to me. "ip route" is a command line tool. The fact that there is a space in it doesn't offend me. In fact, that someone has attempted to design some level of user interface consistency between "ip route" and "ip link" and "ip tunnel" is actually something I consider to be a feature, and the fact that there is single command, "ip", makes discovery of all of the types of network configuration that one might want to do much easier. This style of interface --- also used with "git", "hg", and many others, is arguably nicer in terms of avoiding polluting the command line namespace than the old MH approach of appropriating separate commands, "show", "reply", "next", "prev", "reply", etc. - Ted ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-07 21:10 ` Dave Horsfall 2018-05-07 21:53 ` Steve Johnson @ 2018-05-07 21:54 ` Steve Nickolas 2018-05-08 8:14 ` Mutiny 1 sibling, 1 reply; 29+ messages in thread From: Steve Nickolas @ 2018-05-07 21:54 UTC (permalink / raw) On Tue, 8 May 2018, Dave Horsfall wrote: > On Mon, 7 May 2018, A. P. Garcia wrote: > >> "This is the Unix philosophy: Write programs that do one thing and do it >> well. Write programs to work together. Write programs to handle text >> streams, because that is a universal interface." - Douglas McIlroy, former >> head of Bell Labs Computing Sciences Research Center >> >> https://github.com/sirredbeard/Awesome-UNIX > > Sadly, Penguin/OS appears to have forgotten this, as it becomes more like > Windoze every day... > > -- Dave > I blame people like Lennart Poettering who seem to be hellbent on erasing Linux's origins... -uso. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-07 21:54 ` Steve Nickolas @ 2018-05-08 8:14 ` Mutiny 0 siblings, 0 replies; 29+ messages in thread From: Mutiny @ 2018-05-08 8:14 UTC (permalink / raw) >I blame people like Lennart Poettering who seem to be hellbent on erasing Linux's origins...I don't think so. Red Hat does a extremely good job moving *nix/linux to the 3rd millennia.-uso. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/ffb79674/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-07 18:22 [TUHS] unix "awesome list" A. P. Garcia 2018-05-07 21:10 ` Dave Horsfall @ 2018-05-07 22:34 ` Andy Kosela 1 sibling, 0 replies; 29+ messages in thread From: Andy Kosela @ 2018-05-07 22:34 UTC (permalink / raw) On Monday, May 7, 2018, A. P. Garcia <a.phillip.garcia at gmail.com> wrote: > Hi, > > There's a unix "awesome list". It mentions TUHS's wiki, as well as this > quote: > > "This is the Unix philosophy: Write programs that do one thing and do > it well. Write programs to work together. Write programs to handle > text streams, because that is a universal interface." - Douglas > McIlroy, former head of Bell Labs Computing Sciences Research Center > > https://github.com/sirredbeard/Awesome-UNIX > IMHO this "list" is strangely not distinguishing enough between SYSV and BSD. It seems to put every UNIX into the magical AT&T umbrella. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180507/a7660712/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" @ 2018-05-08 15:17 Noel Chiappa 2018-05-08 15:22 ` Warner Losh 2018-05-08 16:18 ` Arthur Krewat 0 siblings, 2 replies; 29+ messages in thread From: Noel Chiappa @ 2018-05-08 15:17 UTC (permalink / raw) > From: Clem Cole > I agree with Tannenbaum that uKernel's make more sense to me in the long > run - even if they do cost something in speed There's a certain irony in people complaining that ukernel's have more overhead - while at the same time time mindlessly, and almost universally, propogating such pinheaded computing hogs as '_mandating_ https for everything under the sun' (even things as utterly pointless to protect as looking at Wikipedia articles on mathematics), while simultaneously letting Amazon/Facebook/Google do the 'all your data are belong to us' number; the piling of Pelion upon Ossa in all the active content (page after page of JavaScript, etc) in many (most?) modern Web sites that does nothing more than 'eye candy'; etc, etc. Noel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 15:17 Noel Chiappa @ 2018-05-08 15:22 ` Warner Losh 2018-05-08 16:18 ` Arthur Krewat 1 sibling, 0 replies; 29+ messages in thread From: Warner Losh @ 2018-05-08 15:22 UTC (permalink / raw) On Tue, May 8, 2018 at 9:17 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote: > > From: Clem Cole > > > I agree with Tannenbaum that uKernel's make more sense to me in the > long > > run - even if they do cost something in speed > > There's a certain irony in people complaining that ukernel's have more > overhead - while at the same time time mindlessly, and almost universally, > propogating such pinheaded computing hogs as '_mandating_ https for > everything > under the sun' (even things as utterly pointless to protect as looking at > Wikipedia articles on mathematics), while simultaneously letting > Amazon/Facebook/Google do the 'all your data are belong to us' number; the > piling of Pelion upon Ossa in all the active content (page after page of > JavaScript, etc) in many (most?) modern Web sites that does nothing more > than > 'eye candy'; etc, etc. > But I want sshd on my pdp11 so that I can securely log in :( Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/b5d6685a/attachment.html> ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 15:17 Noel Chiappa 2018-05-08 15:22 ` Warner Losh @ 2018-05-08 16:18 ` Arthur Krewat 2018-05-08 19:37 ` Dave Horsfall 1 sibling, 1 reply; 29+ messages in thread From: Arthur Krewat @ 2018-05-08 16:18 UTC (permalink / raw) On 5/8/2018 11:17 AM, Noel Chiappa wrote: > > There's a certain irony in people complaining that ukernel's have more > overhead - while at the same time time mindlessly, and almost universally, > propogating such pinheaded computing hogs as '_mandating_ https for everything > under the sun' (even things as utterly pointless to protect as looking at > Wikipedia articles on mathematics), while simultaneously letting > Amazon/Facebook/Google do the 'all your data are belong to us' number; the > piling of Pelion upon Ossa in all the active content (page after page of > JavaScript, etc) in many (most?) modern Web sites that does nothing more than > 'eye candy'; etc, etc. > Part of the https wave is the fact that the Tin Foil Hat Society thinks they are being maliciously monitored by the gov't. The move towards privacy on the Internet is fostered by this conspiracy-minded thoughtlessness. Meanwhile, it just adds another step to any entity wanting to figure out what you've been doing online. Either monitor your browser (ala telemetry), or the websites themselves. If one were to see https traffic to a website that's known for it's racist content, then that pretty much defines what you've been doing without having to decrypt the actual packets. Much less get your search history from Google in the first place. I've heard this very same privacy concern from what I consider moderately intelligent people I associate with. I have a (very) small website in http that has a few TOPS-10 items for download. That doesn't need to be https, but for some reason, I've heard that Google will lower my rankings because I'm not using https. What tomfoolery is this? ak ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 16:18 ` Arthur Krewat @ 2018-05-08 19:37 ` Dave Horsfall 2018-05-08 19:54 ` Grant Taylor 0 siblings, 1 reply; 29+ messages in thread From: Dave Horsfall @ 2018-05-08 19:37 UTC (permalink / raw) On Tue, 8 May 2018, Arthur Krewat wrote: > I have a (very) small website in http that has a few TOPS-10 items for > download. That doesn't need to be https, but for some reason, I've heard > that Google will lower my rankings because I'm not using https. What > tomfoolery is this? I'll bet my website (about a few feet away from me) is smaller still :-) But yeah. I've been told that I *need* HTTPS, even though the damned site is purely passive... -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM) ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] unix "awesome list" 2018-05-08 19:37 ` Dave Horsfall @ 2018-05-08 19:54 ` Grant Taylor 0 siblings, 0 replies; 29+ messages in thread From: Grant Taylor @ 2018-05-08 19:54 UTC (permalink / raw) On 05/08/2018 01:37 PM, Dave Horsfall wrote: > I'll bet my website (about a few feet away from me) is smaller still :-) Props for hosting your own site. > But yeah. I've been told that I *need* HTTPS, even though the damned > site is purely passive... I think /need/ may be a strong word. I *strongly* believe in the various cache ability aspects of unencrypted HTTP. That being said, I understand and believe in the two following reasons for supporting encrypted HTTPS: 1) Encryption (from a verifiable source) makes it next to impossible for malicious actors to inject things into your site's traffic. (Think about the various JavaScript injection techniques used for ads / tracking / malware / crypto mining / etc.) 2) Creating more noise for someone with higher value signal to hide in when they really need to. Finally, things like Let's Encrypt and other free cert providers make it much less expensive to use encrypted HTTPS. I'm perfectly fine with people running unencrypted HTTP and encrypted HTTPS side by side. Even if you don't do a redirect from unencrypted HTTP to encrypted HTTPS. It's really up to each site administrator. I'm 60% for and 40% against encrypted HTTPS everywhere. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180508/fbee360f/attachment.bin> ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2018-05-09 1:28 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-07 18:22 [TUHS] unix "awesome list" A. P. Garcia 2018-05-07 21:10 ` Dave Horsfall 2018-05-07 21:53 ` Steve Johnson 2018-05-08 12:24 ` Theodore Y. Ts'o 2018-05-08 13:51 ` Bakul Shah 2018-05-08 14:53 ` Clem Cole 2018-05-08 15:23 ` Jon Steinhart 2018-05-08 15:31 ` Steve Johnson 2018-05-08 16:32 ` Clem Cole 2018-05-08 17:33 ` Theodore Y. Ts'o 2018-05-08 18:40 ` William Cheswick 2018-05-08 21:25 ` Bakul Shah 2018-05-08 23:06 ` [TUHS] (early parallel/concurrent computing) (was: unix "awesome list") Lyndon Nerenberg 2018-05-09 0:25 ` Ron Natalie 2018-05-09 1:28 ` Kurt H Maier 2018-05-08 21:15 ` [TUHS] unix "awesome list" Bakul Shah 2018-05-08 16:31 ` Michael Parson 2018-05-08 17:20 ` Larry McVoy 2018-05-08 17:49 ` Michael Parson 2018-05-08 20:48 ` Dave Horsfall 2018-05-08 17:53 ` Theodore Y. Ts'o 2018-05-07 21:54 ` Steve Nickolas 2018-05-08 8:14 ` Mutiny 2018-05-07 22:34 ` Andy Kosela 2018-05-08 15:17 Noel Chiappa 2018-05-08 15:22 ` Warner Losh 2018-05-08 16:18 ` Arthur Krewat 2018-05-08 19:37 ` Dave Horsfall 2018-05-08 19:54 ` Grant Taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).