[HN Gopher] Plan 9 from Bell Labs in Cyberspace
___________________________________________________________________
Plan 9 from Bell Labs in Cyberspace
Author : __d
Score : 678 points
Date : 2021-03-23 13:11 UTC (9 hours ago)
(HTM) web link (www.bell-labs.com)
(TXT) w3m dump (www.bell-labs.com)
| pengaru wrote:
| > That community is organizing itself bottom-up into the new Plan
| 9 Foundation, which is making the OS code publicly available
| under a suitable open-source software license.
|
| Didn't bell-labs already make the source available under the GPL
| years ago? Why is this necessary?
| justin66 wrote:
| Bell Labs permitted UC Berkeley to fork and distribute Plan 9
| under the GPL, but the main repository was still under the
| Lucent Public License or something weird like that. Relicensing
| under the MIT license will maximize the number of people who
| can use the code, even if the foundation they created does not
| catch on.
| [deleted]
| sitharus wrote:
| The source was available but the project was essentially dead.
| You could fork but contributing upstream was hard.
|
| This removes the corporate roadblocks and lets plan9 exist but
| itself.
| nix23 wrote:
| Right, this is why 9front and 9legacy came up and both are
| pretty well maintained, i hope they (9front) migrate the code
| "back" to Plan9, would be amazing to have one single point of
| development.
| milliams wrote:
| Specifically, it seems to be under the MIT license.
| lupinglade wrote:
| Good choice. A truly open source license.
| henvic wrote:
| 2021: the year of the plan9 desktop
| https://twitter.com/j3sj3sj3s/status/1374375432452116485
| nabla9 wrote:
| Huh. Ken Thompson and Rob Pike invented UTF-8. TIL.
|
| https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
|
| >So we went to dinner, Ken figured out the bit-packing, and when
| we came back to the lab after dinner we called the X/Open guys
| and explained our scheme. We mailed them an outline of our spec,
| and they replied saying that it was better than theirs (I don't
| believe I ever actually saw their proposal; I know I don't
| remember it) and how fast could we implement it? I think this was
| a Wednesday night and we promised a complete running system by
| Monday, which I think was when their big vote was.
|
| >So that night Ken wrote packing and unpacking code and I started
| tearing into the C and graphics libraries. The next day all the
| code was done and we started converting the text files on the
| system itself. By Friday some time Plan 9 was running, and only
| running, what would be called UTF-8. We called X/Open and the
| rest, as they say, is slightly rewritten history.
| JulianMorrison wrote:
| If you used Go in the very earliest days, you'll recognise pieces
| of its toolchain in Plan 9.
| mcdevilkiller wrote:
| Even the logo has some resmblance
| ethhics wrote:
| Both made by Renee French, wife of Rob Pike!
| kencausey wrote:
| Who were, I believe, brought together by Penn Jillette.
| floren wrote:
| Years back, I tweaked the Plan 9 kernel source so it could
| compile with Go's C toolchain. After a day or two it was
| booting, but we decided not to use it... I think the end
| conclusion was that the Go team was (reasonably) only
| interested in maintaining the compilers for building Go, and
| that they could at any time make changes that would break our
| builds.
| varispeed wrote:
| I wish the so called open source projects were more inclusive.
| Many people would love to work on these projects, but are unable
| to because they need to have a paid employment to pay bills and
| feed family. Open Source projects give a platform for people from
| privileged background to show off their skills plus they are
| reducing the amount of work available. For example company won't
| hire someone to do X if they can find an open source project that
| does something like X. Big corporations are also exploiting those
| projects and make billions off of them while paying developers
| nothing. In some countries work for free is illegal and a person
| doing the work needs to be given at least a minimum wage.
| Companies who use such software are essentially getting labour
| without paying for it. We need to think about royalty system that
| will be reimbursing people working on those projects and creating
| a level playing field so people from poor backgrounds could also
| participate.
| uhtred wrote:
| Middle class privilege is real.
| adamrt wrote:
| This is the most confusing comment I've seen on HN in years.
|
| > I wish the so called open source projects were more
| inclusive.
|
| - What barrier is there currently to open source projects. Take
| the code, do whatever you want with it.
|
| - What is the difference between an open source project and a
| "so-called open source" project. Is the source available freely
| available? Then its open source. It is a gift!
|
| > Many people would love to work on these projects, but are
| unable to because they need to have a paid employment to pay
| bills and feed family.
|
| Why is that anyone else's problem? Billions of people don't get
| to do exactly what they want to do. Many (most?) open source
| contributors work on the open source in their spare time. "Many
| people would love to do X, but are unable to because Y". You
| can fill in those blanks for anything.
|
| > Companies who use such software are essentially getting
| labour without paying for it. We need to think about royalty
| system that will be reimbursing people working on those
| projects...
|
| They aren't paying for it because the person who wrote it
| didn't want them to pay for it. You are trying to control the
| explicit desires of the person who created and shared the
| software.
| varispeed wrote:
| > What barrier is there currently to open source projects.
| Take the code, do whatever you want with it.
|
| There is a barrier to participate in development of those
| projects. Developers are expected to work for free and not
| every developer can afford to do it, so these projects are
| dominated by people from privileged backgrounds.
|
| > What is the difference between an open source project and a
| "so-called open source" project. Is the source available
| freely available? Then its open source. It is a gift!
|
| I am not sure why do you mean by this question.
|
| > Billions of people don't get to do exactly what they want
| to do. Many (most?) open source contributors work on the open
| source in their spare time.
|
| The problem is that "Open Source" is a source of free R&D for
| companies who don't have to pay salaries and taxes and
| developers are expected to give up their time for free. Big
| companies are promoting this, because it saves them money in
| the long run at the expense of developers. This is the same
| situation as with unpaid internships. If a company offers an
| unpaid internships, only people from privileged backgrounds
| can afford that (e.g. parents pay their bills) and people
| from poor background are missing out because they need to
| find a paid work often in completely different sector. That's
| why in many countries (for example in the UK) unpaid
| internships are illegal to level the playing field and to
| reduce the social divide.
|
| > They aren't paying for it because the person who wrote it
| didn't want them to pay for it.
|
| As I wrote above, in many places it is illegal. Everyone
| should be paid for their work even if they are privileged and
| don't want money (then they can send it to charity).
| adamrt wrote:
| You severely lack any historical context about open source.
|
| You are speaking like it was started by big companies to
| get free labor.
|
| It was literally the opposite. It was started by people who
| wanted to share and have the source code so they could make
| changes and not be beholden to large companies.
|
| You are literally complaining that about GIFTs! It is a
| gift that you can get the source code. You can use it,
| change it, learn from it. You are welcome!
|
| You also keep associating open source to unpaid forced
| labor. What about hobbies?
|
| Please tell me anywhere in the world where it is illegal to
| give away something I created.
|
| It's hard for me to believe you are not trolling. If you
| are not, I don't know how to help you.
| varispeed wrote:
| I know how this started and my idea does not change the
| roots of the movement. Software will be free for
| individuals. The problem is that big corporations
| essentially stole the movement and spun it to get free
| labour. You can also give free labour to another
| individual - for example you can mow your elderly
| neighbour's lawn, but in my country giving free labour to
| a corporation is illegal. Please don't mix the two
| things. One is noble the other is exploitative!
| userbinator wrote:
| That's what used to be called a troll comment. These days,
| the term "SJW" is more commonly used.
| Aloha wrote:
| How do you propose open source projects get the revenue to
| offer a royalty program?
|
| Also, in what countries is volunteering for free illegal?
| harwoodleon wrote:
| Well there's https://gitcoin.co/
|
| Not royalties, but dues at least.
|
| A DAO structure would work well, but not many people seem to
| see it as viable.
| varispeed wrote:
| Royalties should be based on % of revenue generated by a
| product where particular software is being used and
| distributed among contributors. You are conflating
| volunteering with internship. If a company recruits
| volunteers as software developers, this is a disguised
| internship and they'll get themselves liable. This is illegal
| in the UK.
| Aloha wrote:
| and if the open source project generates no revenue?
|
| Like, if Y is controlled by the Y foundation which is in
| part funded by Z company, Y foundation isnt really getting
| a direct revenue stream from the software - thats the thing
| about open source software, you dont have a say in how its
| used, and you cannot force payment.
|
| I think your read of the law on what is or isnt an
| internship is a wee bit of a hot take, but IANAL, and
| certainly not a UK Labor Lawyer.
| varispeed wrote:
| > and if the open source project generates no revenue?
|
| For example 0.1% of 0 is 0
| (https://en.wikipedia.org/wiki/Percentage)
|
| Whoever gets the revenue from the software should be
| paying.
|
| Regarding any constructs with foundations and other tax
| avoidance schemes, that's probably another topic.
| Aloha wrote:
| So, basically, you're saying that if you make money from
| the software, you should be required to pay money to the
| copyright holders (aka, the developers).
|
| At that point, what sets aside open source software from
| any other kind of software?
| devenblake wrote:
| Twitter announcement:
| https://twitter.com/plan9foundation/status/13743504723168174...
|
| Plan 9 Foundation: https://p9f.org/
|
| Wikipedia: https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
|
| There's still a pretty active community around Plan 9, too.
|
| 9Front, a popular fork of Plan 9: http://9front.org/
|
| Interviews with some Plan 9 community members:
| https://0intro.dev/
|
| Some videos: [A Tour of
| Acme](https://www.youtube.com/watch?v=dP1xVpMPn8M), [Peertube
| channel of sigrid's](https://diode.zone/video-
| channels/necrocheesecake/videos)
| _joel wrote:
| https link timing out for me http://p9f.org/
| ori_b wrote:
| Plan 9 is also participating in GSOC this year.
| http://p9f.org/wiki/gsoc-2021-ideas/index.html
| choppaface wrote:
| Rob Pike filled all the application spots himself.
| AceJohnny2 wrote:
| with assistance from Russ Cox
| JAlexoid wrote:
| I've seen Plan 9 in GSoC multiple times, now.
|
| I personally learned about it from GSoC many years ago.
| gpvos wrote:
| I had no idea that Nokia had bought Bell Labs.
| stagger87 wrote:
| More specifically, Nokia bought the parent company of Bell
| labs, Alcatel-Lucent.
| gpvos wrote:
| In 2015 apparently, says wikipedia.
| DVk6dqsfyx5i3ii wrote:
| To provide more context, Alcatel-Lucent was a merger of the
| French Alcatel and Lucent. And Lucent was formed when AT&T
| divested technology business units including Western Electric
| and Bell Labs.
| the_only_law wrote:
| I have a bunch of old telecom / networking / engineering
| equipment from mostly the 80s-90s and it's always fun to
| figure out who owns or owned some IP or product.
| knolan wrote:
| That's nice and all but I'm still salty about how Nokia shuttered
| Bell Labs Ireland last year. So many close friends lost their
| jobs.
| dave84 wrote:
| I hadn't heard, it doesn't seem to have generated much press
| coverage now that I'm giving it a Google.
| knolan wrote:
| It was kept remarkably quiet. That site in particular
| received a lot of support from the IDA over the years so I
| can't imagine they were too happy about it. BLI was told year
| on year that it was a top performing site. Then a few months
| into lockdown they pulled the rug out from under everyone.
| kingosticks wrote:
| Were they working on products? Any examples?
| knolan wrote:
| I'd already left a couple of years. Most Bell Labs stuff
| is closer to research than development anyway.
| kingosticks wrote:
| That's what i thought also which is why I was curious it
| was considered top performing. I suppose there are
| metrics other than profitability to define performance.
| mapcars wrote:
| Allright, but isn't it like 20 year late? And does this contain
| any interesting parts which are not already in 9fans/9front
| build?
| rakoo wrote:
| The cynical view is that it is now official Plan 9 cannot be
| used to make money anymore, so waiving away the remaining
| monopoly rights one may have over it is free positive publicity
| butterisgood wrote:
| And yet Coraid has a Plan 9 based product for ATA over
| Ethernet.
| rakoo wrote:
| Are they using Plan 9 as a commodity (in which case it
| could be replaced by another OS at the cost of
| redevelopping their added value) or are they selling Plan 9
| as a product ?
| sciurus wrote:
| I thought they were dead, but it seems they're back.
|
| https://www.theregister.com/2017/06/26/coraids_athenian_res
| u...
| UnpossibleJim wrote:
| probably, but if this publicity works, there's a slim chance
| that the open source community _might_ be able to rally behind
| it and cobble together a larger interest /community and
| application base to make it a viable personal product.... all
| big IFs.
| moonchild wrote:
| 9front continues to be developed, and though all its changes
| are permissively licensed, the whole is still gpl'd for obvious
| reasons. This allows 9front's code to be opened up.
| erikpukinskis wrote:
| Most big ideas have cyclical openings where they can be
| applied. Kind of like a Mars transfer window.
|
| So, if something had a window 20 years ago, but didn't get
| applied, there's a good chance that another window has opened
| up.
| nonbirithm wrote:
| I wonder what Stanley Lieber would think.
| nsajko wrote:
| The mailing lists _are_ public. I 'm not subscribed to any
| 9front ones, but the people on the cat -v mailing list are
| happy about being able to complete the manual collection now.
| yiyus wrote:
| I wonder what Uriel would think.
| offtop5 wrote:
| Looks like they have a Raspberry Pi version. Might try to see
| what it can do this weekend.
|
| I've always wanted to see more OSes , there has to be a different
| way of doing things then the Unix/Linux / BSD OSX or Windows
| operating systems
| MisterTea wrote:
| Millers pi supports wifi, 9front does not[1]. Though 9front is
| probably more newbie friendly as it has a little more polish
| and a the FQA/docs have been improving greatly as of late.
|
| 1. Millers wifi implementation is different than 9fronts wifi
| so a lot of work needs to be done to get Rich's driver working
| on 9front. Patches welcome :-)
| dylan604 wrote:
| >FQA/docs
|
| Frequently Questioned Answers???
| cat199 wrote:
| indeed. http://fqa.9front.org/
|
| 9front is peppered with extremely dry sarcasm, to the point
| of controversy (http://fqa.9front.org/fqa1.html#1.3.0.1)
| Abishek_Muthian wrote:
| Being distributed operating system can I build a RPi cluster
| with just plan9 installed for distributed computing tasks?
| MisterTea wrote:
| Yes. You can boot the entire cluster from a single file
| server running on any other plan 9 machine be it pi, pc,
| VM, whatever. Each node boots from the same root file
| system so each node has the same fs view. This is where
| ndb[1] comes in Though you can change this any way you see
| fit. Network booting can be accomplished via pxe or a plan
| 9 kernel on sd with a plan9.ini configured to automatically
| pull root via tls or tcp.
|
| have a look at thread(2)[2] and enjoy Go like channels and
| concurrency cleanly built on top of the nice pan 9 c
| library. You could just use Go but we dont have Go on pi
| yet, that's a google SOC 2021 project if anyone is
| interested.
|
| 1. http://man.postnix.pw/plan_9/6/ndb
|
| 2. http://man.postnix.pw/plan_9/2/thread
| michrassena wrote:
| It took me a while to figure out what is meant by Miller's
| pi. I assume the most recent image is the one you're
| referring to, and it does support wifi on the pi, is that
| right?
|
| https://9p.io/sources/contrib/miller/
| williesleg wrote:
| Why does this horse shit keep showing up here? Everybody hated
| AT&T's shit license back then, and now it's freeware? or more
| like free open source abandonware. 30 years too late, pal.
| samtregar3 wrote:
| I was surprised nobody mentioned the OS they built next, after
| Plan 9 - Inferno:
|
| https://en.wikipedia.org/wiki/Inferno_(operating_system)
|
| That's the one I've used and it was pretty cool. Limbo was a fun
| little scripting language.
| nsajko wrote:
| I think Nokia doesn't own Inferno, it was sold to Vita Nuova
| around 20 years ago.
| bear8642 wrote:
| Indeed - there was post recently about port to Lua which want
| to investigate further
| MyrtleTook wrote:
| I don't understand how the "everything is a file" could apply for
| everything in practice. For example, Linux has ioctl(), which in
| practice are like a side channel. Granted, Linux doesn't apply
| this API philosophy too thoroughly.
|
| I guess the "everything is a file" might have multiple meanings.
| For example:
|
| (1) Everything is represented by a (file) descriptor
|
| (2) Same as (1) _and_ the descriptor has a file-like API (think
| read(), seek(), write(), etc.)
|
| (3) Everything is an "byte addressable blob of bytes"
|
| Meaning (1) is OK. But it doesn't tell nothing about the API the
| (file) descriptor itself would use. It could be a fixed set (like
| meaning (2)), or be variable depending on something else (like
| the (file) descriptor type).
|
| Meaning (2) looks like too restrictive and inefficient to me and
| is the one I really have trouble accepting as a general OS
| primitive.
|
| Meaning (3) surely can't be used for everything in practice,
| right? It's just to generic like "every computer architecture can
| be emulated by a universal turing machine." And it also seems too
| inefficient. But it could be very useful if the blob of bytes had
| an API like (2) or any other, including having an API depending
| of the "file type".
|
| Is option (3) that folks are meaning when talking about
| "everything is/should be a file"?
|
| EDIT: formatted the meaning list correctly.
| kragen wrote:
| It's more like #2, but without ioctl() and similar brain-
| damaged abortions. If you open /dev/mouse, for example, you get
| a stream of events (encoded as blobs of bytes), which you can
| get by read(), not a byte-addressable blob of bytes.
|
| But lots of things in Plan9 present an interface that isn't
| just a single file. The 81/2 window system, for example,
| presents not only /dev/mouse but also /dev/cons (character-
| oriented I/O), /dev/bitblt (to which you write requests for 2-D
| accelerated drawing operations), /dev/rcons (keystroke-oriented
| character I/O), and /dev/screen (the contents of the window--
| which _is_ just a byte-addressable blob of bytes).
| http://doc.cat-v.org/plan_9/4th_edition/papers/812/ explains in
| more detail.
|
| And, of course, file storage servers similarly provide an
| arbitrary tree of files, and when you remotely log into a CPU
| server, you mount your local filesystem on the CPU server so
| that processes running on the CPU server can access your local
| files transparently--including /dev/screen, /dev/mouse, and
| /dev/bitblt, if you so choose.
| AceJohnny2 wrote:
| It may be useful to see Russ Cox's "Tour of ACME" video [1].
| ACME is a Plan-9 text editor, which applies the "everything is
| a file" philosophy pretty deeply. It doesn't answer your ioctl
| question (that I remember), but maybe it'll give you a better
| example of how other things can be accessed as files.
|
| [1] https://www.youtube.com/watch?v=dP1xVpMPn8M
| yiyus wrote:
| It's basically your second option. In Plan 9, everything is a
| file server that presents a file system interface that speaks
| the 9P protocol.
| Isamu wrote:
| I agree with you. A type amounts to the sum of operations
| that are valid on an object conforming to that type.
|
| A file object is a very basic, general type, that allows
| open, read bytes, write bytes, close, maybe seek, maybe some
| ops are restricted (read-only, write-only) etc.
|
| I don't think it is generally appreciated how far it gets you
| to have a unifying simple interface. You can always add a
| complex one, you know?
| bogomipz wrote:
| It's interesting both of you had different answers. I realize
| that the streams interface was a Sys V thing but would the
| Unix's "everything is a file" generally be option (2) in the
| OPs comment then? I feel like I've heard the phrase so much
| and just always assumed it was (2.)
| throwaway823882 wrote:
| If Unix is "everything is a file", then Plan 9 is
| "everything is a network filesystem".
|
| If you have a laptop and a desktop, and your desktop has a
| printer attached, can your laptop just print to it? In
| Linux, you have to set up CUPS, open network ports,
| download drivers, and generally set up both machines to be
| able to "talk printers". In Plan 9, your laptop just opens
| the desktop's printer file over the network, and prints.
| discreteevent wrote:
| It's more or less 3. Not everything is a blob but everything is
| a stream of bytes. It think the confusion for most of us (me)
| initially is that a file means a blob that you read in, change
| and then write out more or less atomically. But the Unix
| originaters understood files as streams. So, for example, the
| input stream from your mouse is a file. Everything is a file
| really means everything is a stream.
| jacobvosmaer wrote:
| I think "everything is a file" also means: everything is
| addressable by a file path. Per-process namespaces are part of
| what makes this possible.
|
| In a way it's similar to HTTP REST, which is also organized by
| file paths, except instead of the HTTP verbs GET, POST etc. you
| get open, read, write as your verbs.
|
| A side channel is then just a directory entry.
| throwaway823882 wrote:
| A lot of people miss the fact that Plan 9 was a real distributed
| operating system. It's not just UNIX with a couple features ("ooh
| everything is a file" "ooh UTF8"). You can effortlessly execute
| any program across multiple hosts on a network. You can use any
| resource of any host on the network, including files, processes,
| graphics, networks, disks. It all just works like magic, using a
| single message-oriented protocol.
|
| If Linux worked like this today, you would not need Kubernetes.
| You could run systemd on a single host and it would just schedule
| services across all the hosts on the network. Namespaces would
| already be independent and distributed, so containers would only
| be used for their esoteric features (network address translation,
| chroot environment, image layers). Configurations, files,
| secrets, etc would just be regular files that any process in any
| container on any host could access using regular permissions
| models. About 50 layers of abstraction BS would disappear.
|
| I think because nobody's actually seen how it can work, they
| can't imagine it being this simple.
| chovybizzass wrote:
| What's Plan9?
| Someone wrote:
| FTA:
|
| _"Starting in the late 1980s, a group led by Rob Pike and UNIX
| co-creators Ken Thompson and Dennis Ritchie developed Plan 9.
| Their motivation was two-fold: to build an operating system
| that would fit an increasingly distributed world, and to do so
| in a clean and elegant manner. The plan was not to build
| directly on the Unix foundation but to implement a new design
| from scratch. The result was named Plan 9 from Bell Labs - the
| name an inside joke inspired by the cult B-movie "Plan 9 from
| Outer Space."
|
| Plan 9 is built around a radically different model from that of
| conventional operating systems. The OS is structured as a
| collection of loosely coupled services, which may be hosted on
| different machines. Another key concept in its design is that
| of a per-process name space: services can be mapped on to local
| names fixed by convention, so that programs using those
| services need not change if the current services are replaced
| by others providing the same functionality."_
| nosianu wrote:
| > _inspired by the cult B-movie "Plan 9 from Outer Space."_
|
| It's of course not relevant in the current context but still
| fun so I dare add that it is famous because it's so bad. It's
| known as "worst movie ever". It is worth watching the start
| and a few scenes - even if one does not have the patience for
| the whole thing - just for some laughs. It already starts (4
| minutes in) with a scene in a hilarious airplane cockpit,
| which does not look like one at all (those controls..!). The
| zombies are really funny too.
|
| Full movie: https://youtu.be/Ln7WF78PolA
| Someone wrote:
| Comparing https://m.imdb.com/title/tt0052077/reviews ("Plan
| 9 from outer space? reviews) with
| https://www.imdb.com/title/tt0060666/reviews ("Manos: the
| hands of death" reviews), I don't think it qualifies as
| "worst movie ever".
|
| One of the reviewers of 'Manos' says: _"What can I say
| about a movie so bad that it makes Plan 9 From Outer Space
| look like Casablanca?"_ , another _"I have endured a thing
| or two in my life: Plan 9 from outer space. Hercules
| against the moon men. Godzilla versus Megalon. German
| musical comedies from the early sixties. However, THIS was
| too much for me. About one hour or so into the movie, I
| quit."_
| [deleted]
| Koshkin wrote:
| Maybe the "worst" but at least it's not boring like some
| more recent big-budget ones are. (Incidentally, there's
| some enjoyment to be had watching B-rated movies from the
| late 50s to the 80s.)
| msla wrote:
| "Plan 9" is probably close to the worst film you'd watch
| for fun.
|
| "Manos" is worse to the extent slogging through it is a
| chore, at least without commentary to add some
| entertainment value.
| thesuitonym wrote:
| Imagine if everything they told you about Unix was true. Plan 9
| is the operating system Bell Labs made after Unix, to fix many
| of the problems the designers saw.
|
| That said, it's based around what the designers of _Plan 9_
| thought were problems with Unix. It 's a very opinionated
| operating system. But it has so many ideas that were ahead of
| their time, and in many ways are still lightyears beyond what
| we have now.
|
| It's a really cool piece of computing history, and if you
| haven't tried it, I suggest you look into it, but keep in mind
| that even though it looks and sometimes feels like Unix, it
| very much is not. It's not terribly useful as a daily driver OS
| due to a lack of software, but it's very, very cool.
| outworlder wrote:
| > and in many ways are still lightyears beyond what we have
| now.
|
| How close were they to Lisp Machines? :)
| bitmapbrother wrote:
| >and in many ways are still lightyears beyond what we have
| now
|
| I'm struggling to find these ideas that are lightyears beyond
| what he have now.
| PeterWhittaker wrote:
| Many years ago (30?), the Plan 9 shell, rc, was made
| available for other platforms. I was working at the Big Nerd
| Ranch and ran it everywhere I could (I was doing 2nd/3rd
| level support work that gave me unfettered privileged access
| almost everywhere), until the nascent in-house software
| release process (SRP) caught up and sudo started becoming
| more widespread and privileged access started getting locked
| down.
|
| At that point, I needed muscle memory across all machines
| more than anything else, and switched back to sh (bash was
| still very new and not widely available, csh was born borked,
| and ksh was only available under certain OSes). That was sad.
|
| rc had a beautiful, clean C-like syntax without any csh
| weirdness and was much more powerful than sh. Scripts were a
| joy to write and maintain.
| LukeShu wrote:
| I was going to say, 30 years ago, the 1st edition of the
| actual Plan 9 wasn't yet released (not until 1992), much
| less a clone/port of its shell. But it seems that Byron
| Rakitzis wrote his Unix clone of `rc` in 1991 before Plan 9
| was even out! He based it on Tom Duff's paper which
| described Plan 9's shell.
|
| (Plan 9's `rc` was originally written for 10th edition
| Unix, and would later get ported back to Unix as part of
| Russ Cox's plan9port in 2003.)
| byronr wrote:
| Yes, I did! I used Duff's paper as a reference, and
| relied on the good taste of all my beta testers to guide
| me towards a working shell. Back when source code was
| distributed via shar files in an email.
| PeterWhittaker wrote:
| Thanks for writing rc! I'd forgotten about Duff's paper
| and the exact circumstances of rc's release until I read
| LukeShu's and your replies.
|
| I had a lot of fun with rc....
| byronr wrote:
| It's hosted on github now and still serves as the login
| shell for me and presumably many others!
| [deleted]
| fnord123 wrote:
| > and in many ways are still lightyears beyond what we have
| now.
|
| I think this wildly overstates it. Much of the good
| innovations have been adopted in Linux. 9p exists. /proc was
| adopted (though that was in UNIX first).
|
| One unifying principle of plan9 is that everything is a file.
| But the (POSIX) file api has a lot of limitations. Fuschia,
| in contrast had some nice ideas about different types of file
| (blob/object, log, etc).
| ori_b wrote:
| > I think this wildly overstates it. Much of the good
| innovations have been adopted in Linux.
|
| The main innovation can't be done by addition. With plan 9,
| many special cases are removed. You no longer have to
| wonder what happens if you try to create a Unix socket on
| an NFS file system, and then mmap it: There's just 9p.
| Everywhere.
|
| 9p is nice, but it isn't special. Making the whole universe
| 9p is where the improvement lies.
| cycloptic wrote:
| >You no longer have to wonder what happens if you try to
| create a Unix socket on an NFS file system, and then mmap
| it
|
| How does that work? I don't know the details of any
| implementation, but 9p the protocol appears not to have
| any concept of mmap:
| https://9fans.github.io/plan9port/man/man9/intro.html
|
| I think I see what you mean about 9p not being that
| special, it doesn't seem much different than if Windows
| decided to export every system-level API as a DCOM
| object, that would also get you the same kind of "the
| whole universe is networked" kind of deal.
| ori_b wrote:
| > if Windows decided to export every system-level API as
| a DCOM object, that would also get you the same kind of
| "the whole universe is networked" kind of deal.
|
| The difference is that in Plan 9, there is no 'if', and
| there's no _other_ option for accessing resources. All
| programs interface with the OS and other programs via 9p,
| more or less: Notable exceptions are process creation
| calls like rfork() and exec().
|
| > but 9p the protocol appears not to have any concept of
| mmap:
|
| Correct. Mmap is a kernel feature -- and mmap style stuff
| is only really done for demand paging of binaries at the
| moment. You get a cache miss and a page fault? Backfill
| with a read. Backfilling IO on page fault is really all
| mmap does, conceptually.
| cycloptic wrote:
| >there's no other option for accessing resources
|
| That seems like it would create difficulties in porting
| software there. Please correct me if I'm wrong but the
| original plan9 appears to also have no support for shared
| memory or for poll/select.
|
| >Backfilling IO on page fault is really all mmap does,
| conceptually.
|
| For read-only resources yes, for handling writes to the
| mmapped region, that seems quite broken.
| ori_b wrote:
| Plan 9 is not a posix system. That means it doesn't have
| to deal with legacy posix behavior. If you want unix,
| it's easy to get it.
|
| > For read-only resources yes, for handling writes to the
| mmapped region, that seems quite broken.
|
| No more broken than mmap of nfs. Consistency is hard.
| cycloptic wrote:
| >No more broken than mmap of nfs.
|
| Right, I get that's what you meant, it doesn't seem to
| really change much versus NFS, or DCOM, or whatever. So
| it's unclear what benefit is being provided by 9p here.
|
| Also upon further research I am not sure what you mean by
| this is the only option, plan9 seems to suggest use of
| channels for other types of IPC interfaces, which seem to
| not be the same as 9p and are not necessarily network
| serializable. (Or are they?)
| ori_b wrote:
| Channels are not IPC -- they're a libthread API that
| stays within a shared-memory thread group.
|
| There are few magic kernel devices that don't act like
| 9p, like '#s' which implements fd passing on a single
| node. And the VGA drivers expose a special memory segment
| on PCs to enable configuring VGA devices.
|
| But the exceptions are very few and far in between, and
| affect very few programs.
|
| > _So it 's unclear what benefit is being provided by 9p
| here._
|
| A uniform and simple API for interacting with out-of-
| process resources that can be implemented in a few
| hundred lines of code.
| cycloptic wrote:
| How is that conceptually different from IPC? The graphics
| system appears to somehow pass mouse and keyboard events
| to the client programs over a channel. At least that part
| seems similar to an Unix X11 setup where this would be
| done over a socket.
|
| I guess I just don't see what is conceptually the
| difference here versus something like doing basic HTTP
| over a TCP socket, it seems like the same kind of
| multiplexing. Either way, you still have to deal with the
| same issues: can't pass pointers directly, need to
| implement byte swapping, need another serialization
| library if you want the format to be JSON/XML or if you
| want a schema, etc... So in cases where that stuff isn't
| important, channels would come in handy, but of course
| that is now getting closer to a local Unix IPC. Am I
| getting this right?
| ori_b wrote:
| > How is that conceptually different from IPC? The
| graphics system appears to somehow pass mouse and
| keyboard events to the client programs over a channel.
|
| A thread reads them from a file descriptor and writes
| them to a channel. You can look at the code which gets
| linked into the binary:
| /sys/src/libdraw/mouse.c:61
|
| Essentially, the loop in _ioproc is:
| while(read(fd, event)){ parse(event);
| send(mousechan, event); }
|
| And yes, once you have an open FD, read() and write() act
| similar to how they would elsewhere. The difference is
| that there are no _OTHER_ cases. All the code works that
| way, not just draw events.
|
| And getting the FD is also done via 9p, which means that
| it naturally respects namespaces and can be interposed.
| For example, sshnet just mounts itself over /net, and
| replaces all network calls transparently for all programs
| in its namespace. Because there's no special case API for
| opening sockets: it's all 9p.
| cycloptic wrote:
| Ok I see, that helps, thank you. That seems to be mostly
| similar to evdev on Linux after all, except it requires
| you to use coroutines instead of having an option for a
| poll/select type interface.
|
| To me the problem with saying "no special cases" seems to
| make it quite limited on the kernel side and prevent
| optimization opportunities. For example if you look at
| the file node vtables on Linux [0] and FreeBSD [1] there
| are quite a lot of other functions there that don't fit
| in 9p. So you lose out on all that stuff if you try to
| fit everything into a 9p server or a FUSE filesystem or
| something else of that nature.
|
| [0]: https://elixir.bootlin.com/linux/v5.11.8/source/incl
| ude/linu...
|
| [1]: https://github.com/freebsd/freebsd-
| src/blob/master/sys/kern/...
| ori_b wrote:
| Yes, that's the meaning of no special cases*: it means
| you don't add special cases. But this is why plan 9 has
| 40-odd syscalls instead of 500, and tools can be
| interposed, redirected, and distributed between machines.
| I don't have to use the mouse device from the server I
| logged into remotely, I can grab it from the machine I'm
| sitting in front of and inject it into the program. VNC
| gets replaced with mount.
|
| I don't have to use the network stack from my machine, I
| can grab it from the network gateway. NAT gets replaced
| with mount.
|
| I don't have to use the debug APIs from my machine, I can
| grab them from the machine where the process is crashing.
| GDB remote stubs get replaced with mount.
|
| You see the theme here. Resources don't have to be in
| front of you, and special case protocols get replaced
| with mount; 9p lets you interpose and redirect. Without
| needing your programs to know about the replacement,
| because there's a uniform interface.
|
| You could theoretically do syscall forwarding for many
| parts of unix, but the interface is so fat that it's
| actually simpler to do it on a case by case basis. This
| sucks.
|
| * In kernel devices can add some hacks and special magic,
| so long as they still mostly look as if they're speaking
| 9p. This is frowned upon, since it makes the system more
| complex -- but it's useful in some cases, like the '#s'
| device for fd passing. This is one of the abstraction
| breaks that I mentioned earlier.
| cycloptic wrote:
| That's what I mean though, I see the theme, but it seems
| to me to be about the same as trying to fit everything
| into an HTTP REST API, it all falls apart when something
| comes along that breaks the abstraction. For example if
| you have something that wants to pass a structure of
| pointers into the kernel, you can't reasonably do that
| with 9p, so now you've got a special case. The debug APIs
| can still only return a direct memory mapped pointer to
| the process memory as a special case, the normal case is
| doing copies of memory regions over the socket, no matter
| how large they are. If you want to add compression to
| your VNC thing, or add some more complex routing to your
| network setup, you have to start adding special daemons
| and proxies and translation layers into another socket,
| which is not really different from what you would be
| doing on a more traditional Unix. Or is there another way
| plan9 handles these?
| ori_b wrote:
| These things have already been done with 9p.
|
| > _The debug APIs can still only return a direct memory
| mapped pointer to the process memory as a special case_
|
| Can you point to the special case here?
|
| http://man.cat-v.org/plan_9/3/proc
|
| Because it replaces ptrace, and seems to work perfectly
| fine when I mount it over 9p. It's used by acid, which
| needs no additional utilities:
| http://man.cat-v.org/plan_9/1/acid
|
| > _If you want to add compression to your VNC thing_
|
| Images may be sent compressed. More -- or at least better
| -- formats would be good, but this is done.
|
| http://man.cat-v.org/plan_9/3/draw
|
| For a full implementation of remote login using these
| interfaces, here's the code:
|
| http://shithub.us/ori/plan9front/fd1db35c4d429096b9aff176
| 3f2...
|
| It's a bit complex because it needs to do more than just
| forward mouse, keyboard and drawing -- signals need to be
| interposed and forwarded, and there are a few other
| subtle things that need to happen in the namespace. And
| because it contains both the client and server code. Even
| so, it's still small compared to VNC.
|
| And yes, shithub is hosted on plan 9.
|
| > _or add some more complex routing to your network
| setup, you have to start adding special daemons and
| proxies and translation layers into another socket_
|
| Here are the network APIs.
|
| http://man.cat-v.org/plan_9/3/ip
|
| What kind of complex routing are you talking about, and
| why would it be impossible to implement using those
| interfaces?
| mey wrote:
| 9P is how Microsoft is bridging the filesystem between
| Windows/Linux in WSL2
|
| https://devblogs.microsoft.com/commandline/a-deep-dive-
| into-...
| zozbot234 wrote:
| Linux is not yet a fully distributed OS, and even the basic
| foundational work for that featureset is only just being
| undertaken now (and then mostly as a natural development of
| cointainerization/namespacing features, which you might or
| might not see as drawing from Plan9 itself).
| stormking wrote:
| These "nice ideas about different types of file" are not
| new. On the contrary, before Unix, this was common and it
| was one of the revolutionary approaches of Unix, that files
| - from an OS perspective - should be streams of bytes and
| nothing more.
| fnord123 wrote:
| I think before UNIX there weren't nice APIs for different
| types of file access. It was more like getting a raw
| block device and being told "fill your boots".
|
| stream-of-bytes was the right idea then. It doesn't mean
| it is still right.
| stormking wrote:
| You think wrong, it was exactly the same approach of
| defining a "nice API" for each type of file.
|
| It failed.
| MisterTea wrote:
| > I think this wildly understates it. Much of the good
| innovations have been poorly hammered into Linux.
|
| FTFY.
|
| > 9p exists.
|
| A hacked up version called 9p200.u and later on, 9p2000.l
| which comes laden with posix and unix baggage and of course
| linux baggage in the lase of .l. This is to handle things
| like symlinks and special device file hacks inherited from
| Unix.
|
| > /proc was adopted (though that was in UNIX first).
|
| Linux proc is a mess. Plan 9 proc is just that, the
| interface to running processes. There's no stupid stuff
| like /proc/cpuinfo. wtf is that doing in there?
| http://man.postnix.pw/plan_9/3/proc
|
| > One unifying principle of plan9 is that everything is a
| file. But the (POSIX) file api has a lot of limitations.
|
| Plan 9 is not posix.
|
| > Fuschia, in contrast had some nice ideas about different
| types of file (blob/object, log, etc).
|
| A file is an array of bytes. Why complicate that simple
| approach?
| lucideer wrote:
| > _Linux proc is a mess. Plan 9 proc is just that, the
| interface to running processes. There 's no stupid stuff
| like /proc/cpuinfo. wtf is that doing in there?
| http://man.postnix.pw/plan_9/3/proc_
|
| Do you think Plan 9 /proc would have remained as "clean"
| over time if it were as popular as Linux?
|
| One thing that seems to be something of an axiom is that
| popular interfaces become messy over time. The location
| of /proc/cpuinfo seems to be an individual act of
| vandalism rather than being due to fundamental
| differences in underlying philosophy/approach.
| MisterTea wrote:
| > Do you think Plan 9 /proc would have remained as
| "clean" over time if it were as popular as Linux?
|
| If people are allowed to submit "functionality" patches
| ad-hoc with little to no scrutiny or thought, then yes,
| any project will become a mess.
|
| The general approach taken by plan 9 maintainers is to
| question functionality/feature patches and ask "Who does
| this benefit?" If the answer is only the submitter or
| rare edge cases then the patch is rejected. If the patch
| benefits a large audience, then it is accepted.
|
| But to be fair, Linux is hammered on by large corps who's
| only goal is to make money by vomiting webshit from Linux
| servers. They don't care about simplicity, technical
| details, correctness, or anything like that, so long as
| it increases their bottom line. From my point of view the
| Linux I came to love is long dead.
| zymhan wrote:
| By 9p you mean 9pfs? if so, it "exists" for Linux, but
| that's about all.
| calvinmorrison wrote:
| One can natively mount 9fs on linux and there's also diod
| which exports 9fs. Works well for my setup of local file
| share to both plan9 machines and my linux boxes. I use
| diod because my storage system is running a chunky zfs
| with lots of storage I wanted to share
| rakoo wrote:
| The interesting conclusion of all this is that if everything
| looks like a file, then it doesn't matter what OS it runs on.
| A /dev/screen can be on your local Plan 9, on a remote
| Windows or on your Linux VPS; as long as it respects the
| protocol it doesn't matter. Plan 9 is the host of all this
| experiment but its findings can be (and have been) imported
| in other places.
| dale_glass wrote:
| Is that actually useful in practice?
|
| When you're talking about things like displays, performance
| is extremely important. We're talking about 178MB/s to
| update a full HD screen at 30 fps, which requires
| networking pretty much no normal user has.
| rakoo wrote:
| /dev/screen was an example, in practice as said in the
| sibling comments you'd use drawterm which fulfills
| roughly the same usecase as what ssh or RDP do, so yes,
| the use is there. And you may not need a full HD screen
| at 30 fps to work
|
| But it doesn't stop there. Wanna play local music
| remotely ? /dev/audio is there for that. Want to use a
| machine as a jump server ? Just mount their /net folder
| into yours and any network operation will go through
| them.
|
| The ideas can be used today. I have a folder of Music
| with only lossless songs for personal reasons, but it's
| obviously not perfect for playing from my phone because
| of how large they are. So I had a server that transcoded
| them to Vorbis on-the-fly and served them with FUSE, and
| a sshfs on top of that to serve the transcoded fly to my
| phone. This composition of a common interface might use
| no line of code from Plan 9 but it definitely reuses its
| philosophy.
| effie wrote:
| You are seriously overestimating the needed throughput in
| practice. 60fps 1080p can be streamed with good quality
| over 16Mbps channel (2MB/s). The real problem is lack of
| good open source software that will eliminate the
| annoying latency due to desktop protocols (Xorg...).
| There are things such as SPICE or X2GO or RDP which are
| "OK" but I suspect much better experience is possible.
| The computers are extremely fast already but our software
| is so bad we can't see it.
| MrDOS wrote:
| 178 MB/s is a _calculation_ , not an estimate:
|
| 1,920 x 1,080 pixels @ 24 bits/pixel = 6,220,800
| bytes/frame
|
| 30 frames/s = 186,624,000 bytes/s = 177.98 MiB/s
|
| _You_ are seriously underestimating the simplicity of
| plugging in a video encoder.
| dale_glass wrote:
| But once you introduce a piece of software into the
| middle to make this usable, what's the actual difference
| between this and just using VNC?
|
| At that point it doesn't really matter if the screen is a
| file or not -- you need a compressor that can easily
| provide the output on a network socket, and a client that
| can perform the decoding.
| vidarh wrote:
| You're right that it doesn't matter if it's a file or not
| per se.
|
| What matters - and what the file interface gets you, but
| you can do the same thing in many other ways - is
| introducing the concept of a generic pluggable, chainable
| API.
| mulmen wrote:
| I think this looks at the benefit backwards. 9p allows
| resources to be where they make sense and abstract the
| location from the usage. Running a display over the
| network might not make sense but with 9p it also isn't
| _necessary_. 9p itself allows me to run my GUI locally
| while the data and processing live elsewhere.
| floren wrote:
| In my _work_ , there's not much which requires updating a
| full HD screen at 30 fps... video calls, I suppose.
| Everything else updates small portions of the screen at
| lower rates.
|
| There's a program called drawterm which implements Plan 9
| graphics devices on Linux. You run drawterm locally,
| connecting to a Plan 9 system, and your applications on
| the Plan 9 system draw to your drawterm window over the
| network. I regularly run it at 4k and it performs quite
| well.
| cycloptic wrote:
| I'm guessing these applications do not have any kind of
| animations or smooth scrolling? That would be a simple
| test, make your web browser or your image viewer
| fullscreen in 4K and see if there is lag in the
| scrolling/panning/zooming.
| [deleted]
| hnedeotes wrote:
| There's been some post about upscaling algorithms here
| lately, perhaps they could be used for diminishing the
| required bandwidth?
| jdsully wrote:
| 178MB/s is under 1.5 gb/s. It's only because we've been
| stuck with slow gigabit Ethernet for 20 years that we
| think this is a hard problem.
|
| 10G ethernet can do it no problem and fractional speed
| like the 2.5 and 5 gigabit standards should have little
| issue as well.
| dale_glass wrote:
| I concur that it sucks that Ethernet is in a rut for some
| reason.
|
| But even on 10G that's no picnic. Sure, that works for a
| single user, but add a few more people and it's not hard
| to run into trouble. Such a system can't for instance
| just drop frames when the network is overloaded which to
| me makes this more of a curiosity than something anybody
| would actually want to use in practice.
| jdsully wrote:
| 10G switches are old hat and can do full x-bar switching
| at 10G, unless your using very old tech got off ebay you
| shouldn't have issues.
|
| Trunk lines of 100G and higher are pretty common in core
| networks now, if your big enough to span a single switch.
| The main limit was we had trouble doing 10G over cat-5e
| copper with long distances. 2.5/5 solve that problem and
| 10g is possible with cat-6. Fibre has no issue with super
| high rates for network backhauls to aggregate all that
| traffic.
|
| With the exception of the copper standards all of this
| has been roled out in the datacenter for years and is
| pretty mature.
| [deleted]
| 6pac3rings wrote:
| The Plan9 abstractions give me the impression you can network
| as One the top 5 superduper computers and get beyond the
| benchmark metrics that haven't given us machines as intelligent
| and sensible as 3 to 7yo.
| MisterTea wrote:
| https://www.cs.cmu.edu/~410-s14/lectures/L31_P9.pdf
|
| Well explained in this PDF.
| CalChris wrote:
| It's a file.
| goatinaboat wrote:
| You're a file
| Shared404 wrote:
| Can I be a file?
| andrewflnr wrote:
| You're a file! And you're a file! Everyone is a file!
| 0xdeadbeefbabe wrote:
| Not everyone can echo > ctl though
| Koshkin wrote:
| A person is a phile, not 'file.'
| goatinaboat wrote:
| I don't know why this is flagged, I'm observing the point
| that a user, like everything else, is a file
| de6u99er wrote:
| I scream, you scream, we scream for ice cream.
| Angostura wrote:
| https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
|
| Plan 9 from Bell Labs is a distributed operating system,
| originating in the Computing Science Research Center (CSRC) at
| Bell Labs in the mid-1980s, and building on UNIX concepts first
| developed there in the late 1960s. The final official release
| was in early 2015.
|
| Under Plan 9, UNIX's everything is a file metaphor is extended
| via a pervasive network-centric filesystem, and the cursor-
| addressed, terminal-based I/O at the heart of UNIX-like
| operating systems is replaced by a windowing system and
| graphical user interface without cursor addressing, although
| rc, the Plan 9 shell, is text-based.
| [deleted]
| knorker wrote:
| It 503's, or when it loads has a blank page.
|
| Oh how the mighty have fallen.
| dangerbird2 wrote:
| HN hug of death
| 0xdeadbeefbabe wrote:
| AFAIK, the mighty still have to cope with the systems that won
| the popularity contest.
| rcarmo wrote:
| Hmmm. Might be coincidence, but today I noticed Inferno was back
| on GitHub as well (it had been living on Bitbucket):
| https://github.com/inferno-os/inferno-os
|
| This is great news altogether - I've been dabbling with Plan9 for
| a fair bit (mostly on Raspberry Pis of late as they are nicer
| "disposable" machines and I have plenty of them), so am hopeful
| that this will lead to more modern versions (especially something
| whose UX does not rely on mouse chording, which is a chore on
| modern machines).
| samtregar3 wrote:
| Inferno was fun back in the day - Limbo is a neat language with
| some interesting features.
| neilv wrote:
| Kudos to Nokia on a great move.
| haolez wrote:
| Plan9 is the definite proof that Worse is Better[0].
|
| [0] https://en.wikipedia.org/wiki/Worse_is_better
| mseepgood wrote:
| Sure, Unix and Linux are worse than Plan 9, but I don't think
| that's the reason why they are more popular.
| haolez wrote:
| That's not the point of Worse is Better. The point is that,
| in this context, Unix and Linux are better than Plan 9, but
| for non-intuitive reasons.
| discreteevent wrote:
| Worse is better is just annoying. Better at what? Domino's
| pizza is better at market share. It's not better at making
| good pizza. Most people can agree with these two
| statements. But just saying "Domino's is proof that worse
| is better" causes unnecessary arguments
| samatman wrote:
| Pizza has weak network effects.
|
| The capitalization, brand recognition, and streamlined
| corporate franchise structure, cooperate to make it
| easier to launch and run a Domino's franchise, than to
| start a pizza joint from scratch.
|
| But not _that much_ easier. There is plenty of room to
| market better pizza for more money.
|
| Computer systems tend to have strong network effects,
| there's a lot to learn and a skilled developer is,
| ceteris paribus, more productive than a greenhorn. Most
| of the value in operating systems and programming
| languages is in the ecosystem rather than the core.
|
| Worse is better isn't a universal solvent, there are
| plenty of areas where it isn't applicable. The original
| essay+ is about why C and Unix were eating Lisp's lunch,
| and is worth reading.
|
| +
| https://www.dreamsongs.com/Files/LispGoodNewsBadNews.pdf
| discreteevent wrote:
| Sure. So to qualify what you are saying: C is better at
| achieving broad usage. But it is not better than Zig for
| writing secure software. It is not better than perl for
| text processing.
| nix23 wrote:
| Better for what?
| chaganated wrote:
| Gabriel is coping. In Plan9's case, better is better.
| 0xdeadbeefbabe wrote:
| Does this include sam?
| fhs wrote:
| Yes, of course. Acme also.
| shp0ngle wrote:
| Nokia is still around?
|
| ...didn't they get bought by Microsoft and then jumped off a
| cliff?
|
| Well I guess someone is still paying for Qt so I guess they still
| are around
| milliams wrote:
| Nokia sold Qt
| unixhero wrote:
| You mean that they jumped off a proverbial burning platform.
|
| https://www.google.com/amp/s/amp.theguardian.com/technology/...
| majewsky wrote:
| Ungoogled link: https://www.theguardian.com/technology/blog/2
| 011/feb/09/noki...
| vesinisa wrote:
| Nokia is a communications conglomerate. They sold the mobile
| phone manufacturing division to Microsoft in 2014. They still
| have large operations in other networking technologies. Qt has
| also since been sold off and is being again developed by
| Trolltech, now known just as Qt Company.
| isaacimagine wrote:
| I'm reading this on a Nokia!
| distances wrote:
| That's part of their current business: the name is licensed
| for HMD Global, which then outsources production to
| Foxconn. It's Nokia in name only, literally. Seem to be
| very good phones though.
| larschdk wrote:
| HMD was established, by Nokia, to produce phones, since
| Nokia wasn't allow to under the agreement with Microsoft,
| and is run by ex-Nokia executives. HMD bought "back" the
| Nokia Mobile division from Microsoft. Nokia holds shares
| in HMD. nokia.com sells the HMD phones. It is a bit more
| Nokia than just by name.
| isaacimagine wrote:
| Yeah, the phones run Android One (so stock android, no
| bloat), and pretty solid in terms of construction (not
| 3310 level, but I've dropped it a number of times and it
| still seems to be working well).
| input_sh wrote:
| They're pretty much the only ones still releasing Android
| One models. Out of 6 new Android One phones in 2020, five
| were Nokia.
|
| I'm scared Android One is dying, Pixels are prohibitively
| expensive, and I'll have nowhere to jump ships once my
| current Nokia dies.
| t90fan wrote:
| Lenovo make Android One phones.
|
| I got a new Moto G Pro from them this year. Very good
| phone for the price.
| input_sh wrote:
| Yup, that's the sixth one. Other than that one and a few
| Nokias, there's nothing new since the beginning of 2020.
| distances wrote:
| Pixel A phones are very good all-rounders in the midprice
| segment. I know lots of people won't pay 350EUR$ for a
| phone but I find them to be pretty good value at that
| price point.
| zozbot234 wrote:
| Unfortunately it seems that HMD's Nokia phones do not
| support OEM boot unlock, unlike many other Android One
| models. So no running Plan9 on your Nokia phone.
| _jal wrote:
| I try to remind myself how small this little corner of the
| technology world I live in is, and still lose perspective
| sometimes.
|
| If your career is, say, playing client-server ping-pong with
| JSON blobs, it can be really useful to look around at other
| industries and see what they're up to. The commonalities
| quickly give way to some interesting problems and
| perspectives.
| tpmx wrote:
| I like this approach. I make it a point to try to
| understand other industries that I came across in daily
| life.
|
| So much information is out there - you just need to learn
| basic research techniques and be patient/curious. Learning
| to understand financial statements is also a big one.
|
| Why am I doing this?
|
| a) Curiosity. I want to understand how the world works.
|
| b) I'm looking for some niche industry market that can be
| improved, in some plausible way. By the way: There's _so
| much_ weird market segmentation going on in most other
| industries than software.
| dylan604 wrote:
| >developed by Trolltech
|
| I don't think I could ever take software seriously from a
| company name like that. Are these issues really bugs, or are
| we being trolled?
| billiam wrote:
| Trolls as in the Norwegian national mascot, unless you are
| in reality a S#%tposter from Bergen playing 12-D chess and
| trolling us.
| jsilence wrote:
| Isn't that a Norwegian or Icelandic company? Where live
| Trolls live out in the wild?
| stormqloud wrote:
| Tires conglomerate, that started a communications company.
| Nokia tires are pretty good.
| fabioborellini wrote:
| This is not correct. Nokian Tyres was spun off Nokia
| already in 1988, it was listed in 1995 and Nokia sold its
| remaining shares in 2003. Nokian Tyres is still listed in
| Helsinki stock exchange.
|
| Currently Nokia is focusing on mobile networks and patent
| licensing.
| distances wrote:
| Different companies though, Nokia hasn't had any ownership
| in Nokian Tyres since 2003.
| jabl wrote:
| Well, yeah, Nokia WAS a conglomerate that made all kinds of
| things like paper, electricity generation, cables, rubber
| boots, tyres, PC clone computers, and whatnot. But in the
| early 1990'ies all the rest were spun off and since then
| Nokia has been focused on the telecom business.
|
| https://en.wikipedia.org/wiki/Nokia#History
| OldHand2018 wrote:
| > They still have large operations in other networking
| technologies
|
| Indeed, Motorola sold their mobile network infrastructure
| business to Nokia.
| [deleted]
| ksec wrote:
| Using a Smartphone? Nokia collecting patent royalty on 4G/5G as
| we speak.
|
| On a Mobile Network? You can bet with very high chance some
| part of the network are running on Nokia. Broadly speaking
| carriers like to use every vendor they have in part of their
| network just to have vendors competing on price.
|
| Using DSL or Fttx Fibre at at home, you can bet somewhere along
| that fibre there is an Nokia or your DSL Modem is Nokia.
|
| They might not be a household name, but they are still
| everywhere.
| kingosticks wrote:
| Also a decent chance your fixed-network connection is going
| through a Nokia edge/core router along the way.
| nix23 wrote:
| WOW, thank you very much Nokia!!
|
| Having said that..i installed 3 days ago a 9front "cluster",
|
| 2x RPI3 as cpu server
|
| 1x RPI2 with 2 external HD's (2x7TB) as Storage Server
|
| 1x RPI2 (down-clocked) as Auth Server
|
| Love it to work and play with it.
___________________________________________________________________
(page generated 2021-03-23 23:00 UTC)