8 ms·

NetBSD on a JavaStation

166 points by jaypatelani 2y ago

dleslie 2y ago
> After many months of searching I found a Mr Coffee JavaStation for sale in Canada; unfortunately the seller only accepted payments through a Canadian banking service which is pretty much inaccessible outside Canada. If they mean Interac E-Transfers, then their inability to access it may have prevented them from running afoul of a common scam. Online classified ads will offer desirable items that are also often expensive and niche, and will ask the would-be purchaser to pay for it via an e-Transfer. And then you never hear from them again. Always ensure the product exists, or the service is rendered, before using Interac E-transfer. https://www.getcybersafe.gc.ca/en/e-transfer-fraud-protect-your-online-transactions https://www.getcybersafe.gc.ca/en/e-transfer-fraud-protect-y...
- toast0 2y ago
  Only delayed. Eventually they had a friend move to Canada in order to straw purchase the JavaStation on their behalf. (Maybe there were other motivations for moving to Canada, like ketchup chips)
  - dleslie 2y ago
    Ah, I didn't read much past what I quoted; I became distracted.
- 486sx33 2y ago
  Maybe you’re missing part of the point… you can’t send an interac transfer from a US bank account, so unless you have a Canadian bank account, you can’t do it !
  - mardifoufs 2y ago
    Yes but usually listings that ask for interac e-transfers are a scam in the first place! They are basically impossible to revert to scammers really like them. So even if they had access to interact transfers, they probably shouldn't have bought the listed item anyways.
markus_zhang 2y ago
> Sun’s bootloader environment from that period was called OpenBoot, and consisted of a FORTH interpreter, from which you can interrogate the device tree and pretty much do whatever you want. This sounds interesting. I have read quite a few FORTH posts on HN but never gave the thing a look. It is really different than anything I have looked at. For example, for functional languages I never got pass Scheme's ' symbol, but at least I get most of the syntax. FORTH really is another level.
- eschaton 2y ago
  This was the basis for IEEE-1275 Open Firmware, which nobody uses any more but was the standard for SPARC, PowerPC, and post-PowerPC POWER. It’s where device trees came from and frankly is how everything should be booting these days, not u-boot or UEFI or custom secure boot chains (which are entirely possible with Open Firmware too). There are BSD, GPL, and other Open Source variants of Open Firmware you can get and fool around with today and if you’re building a new product you should still consider whether an Open Firmware would work for you versus one of its inferior successors.
- DonHopkins 2y ago
  https://news.ycombinator.com/item?id=33681531 https://news.ycombinator.com/item?id=33681531 I've frequently written about Mitch Bradley's Forthmacs / Sun Forth / CForth / OpenBoot / OpenFirmware on HN. I was his summer intern at Sun in 1987, and used his Forth systems in many projects! [...] https://news.ycombinator.com/item?id=29261810 https://news.ycombinator.com/item?id=29261810 Speaking of Forth experts -- there's Mitch Bradley, who created OpenFirmware: [...] Here's the interview with Mitch Bradley saved on archive.org: https://web.archive.org/web/20120118132847/http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmware-olpc/ https://web.archive.org/web/20120118132847/http://howsoftwar... I've previously posted some stuff about Mitch Bradley -- I have used various versions of his ForthMacs / CForth / OpenFirmware systems, and I was his summer intern at Sun in '87! Mitch is an EXTREMELY productive FORTH programmer! He explains that FORTH is a "Glass Box": you just have to memorize its relatively simple set of standard words, and then you can have a complete understanding and full visibility into exactly how every part of the system works: there is no mysterious "magic", you can grok and extend every part of the system all the way down to the metal. It's especially nice when you have a good decompiler / dissassembler ("SEE") like ForthMacs, CForth, and OpenFirmware do. https://news.ycombinator.com/item?id=9271644 https://news.ycombinator.com/item?id=9271644 [...] https://news.ycombinator.com/item?id=38689282 https://news.ycombinator.com/item?id=38689282 Mitch Bradley came up with a nice way to refactor the Forth compiler/interpreter and control structures, so that you could use them immediately at top level! Traditional FORTHs only let you use IF, DO, WHILE, etc in : definitions, but they work fine at top level in Mitch's Forths (including CForth and Open Firmware). [...] https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/cforth https://github.com/MitchBradley/cforth
neilv 2y ago
> Hard as it may be to imagine, there was a time when Java was brand new and exciting. Long before it became the vast clunky back-end leviathan it is today, it was going to be the ubiquitous graphical platform that would be used on everything from cell phones to supercomputers: write once, run anywhere. > Initially I drank the kool-aid and was thrilled about this new “modern” language that was going to take over the world, and drooled at the notion of Java-based computers, containing Java chips that could run java byte-code as their native machine code. Exactly. I was lucky to see Java when it was still called Oak, and then I developed some of the first (non-animation) Java applets and small desktop applications outside of Sun/JavaSoft. It was very exciting (speaking as a programmer in C, C++, Smalltalk, a little Self, a little Lisp, and other languages at the time). The language itself wasn't as cool as Lisp or Smalltalk, but it was a nice halfway compromise from C++, with some of its own less exotic but nice features and ergonomics. It was already in the browsers, had next-gen embedded systems for the Internet at the forefront from the beginning, there was a proof-of-concept of a better kind of Web browser using it, Sun putting even putting it in rings for ubiquitous computing, there were thin clients that could get interesting (combined with Sun's "The Network Is The Computer", even if historically techies didn't like underpowered diskless workstations, except to give to non-techies), etc., and it only promised to get better... Then I turned my back for a sec., and the next time I looked, Java had been kicked out of the browser, and most all of the energy (except for the Android gambit) seemed to be focused on pitching Java for corporate internal software development. And suddenly no one else seemed to want to touch it, even if there wasn't much better. (Python, for example, from the same era, was one person's simplified end user extension language; and not intended for application development.) Yet another case of technology adoption not going how you'd initially think it would.
- markus_zhang 2y ago
  I'm curious about what happened. IIRC, as you mentioned too in your reply, that Java was supposed to run in embedded devices. It was supposed to be lean and fast. But I can't imagine the modern Java doing that...
  - toast0 2y ago
yjftsjthsd-h 2y ago
Odd that it uses RARP to get an IP but then uses DHCP for NFS configuration. (Or is it the baked in firmware using RARP and then the modern NetBSD kernel using DHCP? That would make more sense) Also: > You need to rename the file with a specific format: the IP address of the JavaStation, but in 8 capitalized hex digits, followed a dot, and then the architecture (in this case “SUN4M”). So, in this example the IP address (as defined in rarpd above) is 192.168.128.45, which in hex is C0A8802D. This is of course the correct way to do it, but if you're lazy you can just tail the tftpd logs and see what filename it tries to download, rename the file on the server, and reboot again to pick it up. (I did this when netbooting raspberry pis)
- toast0 2y ago
  > Or is it the baked in firmware using RARP and then the modern NetBSD kernel using DHCP? That would make more sense Yes, firmware only knows how to use rarp and tftp to fetch a kernel or a better bootloader, kernel is modern and speaks DHCP. This is a pretty common pattern with netbooting; some will bootp rather than rarp, sometimes you use tftp to fetch something that can do an http fetch, etc. Always lots of fun :D
  - eb0la 2y ago
    A lot of old hardware uses TFTP and RARP to boot. RARP just will get you the ip address, and the rest is hardcoded somehow in the machine - needs very little memory on boot. For BOOTP you need some intelligence to know where are your files. TFTP is also cheap in memory to use. UDP without flow, no nothing. Just send me the next packet in sequence when I ask you to do so. I remember having trouble some years ago upgrading old Cisco routers because the image was bigger than what TFTP can handle.
ephaeton 2y ago
I dearly remember setting up NetBSD on various sparc stations and ultra sparcs (a II, and an Ultra 60) and running them alongside a set of various other RISCs and CISCs of late 90s. Based on the paper 'attack of the lemmings' (IIRC) by matthias something (IIRC), I wanted to create a 'how to portably code C' course that would run with just the basic netbsd tools - compiler, editor, test system, make, ... - write once, commit, have the whole weird-ass machine park response to the unit test for a given exercise. Sadly never made it happen fully. Still - NetBSD! fun times, great documentation and such a knowledgeable crowd! Enjoy the voyage!
- chasil 2y ago
  I am assuming that the major reason that you wanted to do this is that SPARC is big-endian. It works in the native order of TCP/IP, and the hton/ntoh macros are null at the socket level in C. NetBSD can run Raspberry Pis big-endian. This is a much easier platform to obtain and configure than SPARC. The targets appear to be earmv7hfeb and aarch64eb. https://wiki.netbsd.org/ports/evbarm/ https://wiki.netbsd.org/ports/evbarm/
  - ephaeton 2y ago
    yeah, machines of different endianness, and, ideally, different alignment requirements. Always wanted to get an alpha, as well. Had hpux / hp300 ?, sparc, sparc64, 386, x86_64, maybe another arch. This was in 2005'ish, mind you. Idea was to write code that would portably work on linux and netbsd on at least said architectures, ideally more.
  - DonHopkins 2y ago
    I has having lunch with some hardware designers from SGI and Sun, and the SGI people mentioned jokingly that the MIPS could be both big-endian and little-endian, which they called SPIM. Then they pointed out much to the embarrassment of the Sun people (including me at the time) that the little-endian version of the SPARC would be called CRAPS.
dehrmann 2y ago
> Java chips that could run java byte-code as their native machine code. Hah! Even ISAs are somewhat detached from truly native machine code, these days.
deadlyllama 2y ago
I remember when Java was exciting. There were several attempts at open source Java OSes like JOS (https://jos.sourceforge.net/ https://jos.sourceforge.net/). A Java applet runtime for the PalmPilot. My thesis on dynamic aliasing protection was based on a dynamic Java-esque runtime. But... Java got a reputation for being heavyweight. And yes, as others have said, instead we got the modern web, with (for example) web based word processors requiring orders of magnitude more compute power than a desktop of the early Java era.
- pjmlp 2y ago
  Don't forget Electron mess.
- okeuro49 2y ago
  I can remember trying to run applets on a consumer machine. It wasn't a good experience. In the meantime, computers became fast enough to run the modern web. The average phone can run tens of these web based wordpressors.
  - jeroenhd 2y ago
    Web applets were a terrible experience all round. Downloaded JAR files usually just worked, though. The GUI looked odd because it wasn't using normal operating system controls, but in terms of performance it was no slower than any native program except for in the most extreme cases. Java on the web was pretty terrible from beginning to end, but The Java Web could've worked. Now that we have the web, we're moving back to the Javaverse in the form of apps (which, on Android, are actually Java(-like)). Every big website has one of those "for the full experience, download our app" banners. Other sites use WASM to bring back the Java applet days, now without third party plugin full of security holes. Google Docs renders to a virtual canvas in the browser in the same way an applet would've back in 2003, except it would've been able to open files directly from the file system. And lo and behold, the new system is also a terrible experience.
    - mark_undoio 2y ago
torcete 2y ago
I remember doing this when I was working for Sun Microsystems. We had to install Solaris in a quite large number of Sun computer for a big client and we did all of them with tftp.
- bayindirh 2y ago
  Big fleets are still installed with TFTP + HTTP/FTP.
  - torcete 2y ago
    I had no idea. Interesting and cool at the same time!
    - bayindirh 2y ago
      It's very cool. Getting a couple racks of new servers and installing all of them from your desk without any interaction is very enjoyable. I also love installing/cabling servers, but not needing to leave your desk to (re)provision hardware is pretty life changing. Considering your desk can be anywhere around the world due to work travels.
- DonHopkins 2y ago
  Are you the poor Unix system administrator at Sun with the Worst Job in the World, who had to install Solaris on Scott McNealy's and Ed Zander's and other VP's workstations? The Worst Job in the World, from Michael Tiemann <tiemann@cygnus.com>: https://www.donhopkins.com/home/catalog/unix-haters/slowlaris/worst-job.html https://www.donhopkins.com/home/catalog/unix-haters/slowlari... PS: Fuck Trump supporting anti-vaxer Scott "You have zero privacy, get over it" McNealy. May he run Solaris in hell. If you installed it on him, then good for you, he deserved it! Scott McNealy has long been one of Trump’s few friends in Silicon Valley: https://www.sfchronicle.com/politics/article/Scott-McNealy-has-long-been-one-of-Trump-s-few-14447197.php https://www.sfchronicle.com/politics/article/Scott-McNealy-h... Former Sun Micro CEO Scott McNealy, known for his provocative quotes, says Trump is doing a 'spectacular job' amid the coronavirus crisis. That's not how many tech experts see it: https://www.businessinsider.com/scott-mcnealy-praises-trumps-handling-of-coronavirus-crisis-2020-3?international=true&r=US&IR=T https://www.businessinsider.com/scott-mcnealy-praises-trumps... Sun on Privacy: "Get Over It": https://www.wired.com/1999/01/sun-on-privacy-get-over-it/ https://www.wired.com/1999/01/sun-on-privacy-get-over-it/
hiAndrewQuinn 2y ago
>The Java-chip thing proved more difficult to realize than anticipated I've been very slowly upping my Java-fu over the past year or so to crack into the IC market here in the Nordics. Naturally I started by investigating the JVM and its bytecode in some detail. It may surprise a lot of people to know that the JVM's bytecode is actually very, very much not cleanly mappable back to a normal processor's instruction set. My very coarse-grained understanding is: If you really want to "write once, run anywhere", and you want to support more platforms than you can count on one hand, you eventually kind of need something like a VM somewhere in the mix just to control complexity. Even moreso if you want to compile once, run anywhere. We're using VM here in the technical sense, not in the Virtualbox one - SQLite implements a VM under the hood for partly the same reason. It just smooths out the cross-compilation and cross-execution story a lot, for a lot of reasons. More formally: A SQLite database is actually a big blob of bytecode which gets run atop the Virtual DataBase Engine (VDBE). If you implement a VDBE on a given platform, you can copy any SQLite database file over and then interact with it with that platform's `sqlite3`, no matter which platform it was originally built on. Sound familiar? It's rather like the JVM and JAR files, right? Once you're already down that route, you might decide to do things like implement things like automatic memory management at the VM level, even though no common hardware processor I know has a native instruction set that reads "add, multiply, jump, traverse our object structure and figure out what we can get rid of". VDBE pulls this kind of hat trick too with its own bytecode, which is why we similarly probably won't ever see big hunking lumps of silicon running SQLiteOS on the bare metal, even if there would be theoretical performance enhancements thataways. (I greatly welcome corrections to the above. Built-for-purpose VMs of the kind I describe above are fascinating beasts and they make me wish I did a CS degree instead of an EE one sometimes.)
- jraph 2y ago
  > It may surprise a lot of people to know that the JVM's bytecode is actually very, very much not cleanly mappable back to a normal processor's machine code or instruction set I believe this is a very sensible decision: being too close to a real architecture would probably tie the bytecode to similar architectures too much and make it quite useless as opposed to compiling to an actual architecture. The bytecode being abstract enough is likely a good thing to be able to achieve okay performance everywhere. Like, you wouldn't want the bytecode to specify a fixed number of registers. What may also surprise many people thinking Java is a bloated language is that the Java bytecode is actually quite simple, straightforward to understand, clean and also very well documented. It's an interesting thing to look into, even for someone not involved day to day in some Java.
chasil 2y ago
"Thankfully, despite its age and total lack of security, NFS is still well supported under Linux." NFSv4 can run over TCP, which means that any encrypted wrapper can carry it. While SSH port forwarding can be used, stunnel is a better fit for batch environments. Wireguard is another option from this perspective. Encrypted ONC RPC works at a lower level of the protocol to secure NFS, which is documented in RFC-9289. Obviously, none of this will help with a machine using RARP and TFTP over 10baseT.
- DonHopkins 2y ago
  NFS originally stood for "No File Security". https://news.ycombinator.com/item?id=33384073 https://news.ycombinator.com/item?id=33384073 Speaking of YP (which I always thought sounded like a brand of moist baby poop towelettes), BSD, wildcard groups, SunRPC, and Sun's ingenuous networking and security and remote procedure call infrastructure, who remembers Jordan Hubbard's infamous rwall incident on March 31, 1987? https://news.ycombinator.com/item?id=31822138 https://news.ycombinator.com/item?id=31822138
  - EvanAnderson 2y ago
    > NFS originally stood for "No File Security" I often heard a different "F" word in that acronym in place of "File".
tomaytotomato 2y ago
> Hard as it may be to imagine, there was a time when Java was brand new and exciting. Long before it became the vast clunky back-end leviathan it is today, it was going to be the ubiquitous graphical platform that would be used on everything from cell phones to supercomputers: write once, run anywhere. As someone who started their software career at Java version 8, I wouldn't say the trend in Java has been to become more clunky. If we separate frameworks from the core libraries of Java, its more modular, has better functionality with things like Strings, Maps, Lists, Switch statements, Resource (file, http) accessing etc.etc. For frameworks we have Spring Boot, which can be as clunky or as thin as you want for a backend. For IC cards, and small embedded systems, I can still do that in the newer versions of Java just with a smaller set of libraries. Maybe the author is nostalgic for a time (which I didn't experience - was busy learning how to walk), but Java can do all the things JDK version 1 can, and so much more. No?
- MisterTea 2y ago
  > write once, run anywhere. Was such a great promise. I remember visiting PCExpo in the late 90's and Sun's booth had a Java demo running on three machines: Linux x86, Windows X86 and Solaris Sparc (OSX wasn't even revealed yet). You could run a few demos you selected from a menu one of which was a 3D ship with accelerated OpenGL which really thrilled me - cross platform everything, even CAD and gaming. Amazing! The future is finally here. And it never happened. Bummer. Instead we got a badly hacked up hypertext viewer with various VM's duck taped to the sides.
- seabrookmx 2y ago
  I don't think the comparison is new Java to old Java, I think it's Java vs. it's competitors. When Java was new, scripting/dynamic languages hadn't matured enough to be true competitors so you were left with C/C++, Delphi and the like. In that landscape, Java is beyond exciting. Nowadays there are so many alternatives that didn't exist then. And it's not debatable that many of those languages (Dart, C#, Typescript, Kotlin) move faster when it comes to language features. Whether you want/need them is subjective, sure. But back in the day Java was that hot, fast moving language.

166 points by jaypatelani 2y ago

> After many months of searching I found a Mr Coffee JavaStation for sale in Canada; unfortunately the seller only accepted payments through a Canadian banking service which is pretty much inaccessible outside Canada. If they mean Interac E-Transfers, then their inability to access it may have prevented them from running afoul of a common scam. Online classified ads will offer desirable items that are also often expensive and niche, and will ask the would-be purchaser to pay for it via an e-Transfer. And then you never hear from them again. Always ensure the product exists, or the service is rendered, before using Interac E-transfer. https://www.getcybersafe.gc.ca/en/e-transfer-fraud-protect-your-online-transactions https://www.getcybersafe.gc.ca/en/e-transfer-fraud-protect-y...

toast0 2y ago
Only delayed. Eventually they had a friend move to Canada in order to straw purchase the JavaStation on their behalf. (Maybe there were other motivations for moving to Canada, like ketchup chips)
- dleslie 2y ago
  Ah, I didn't read much past what I quoted; I became distracted.
486sx33 2y ago
Maybe you’re missing part of the point… you can’t send an interac transfer from a US bank account, so unless you have a Canadian bank account, you can’t do it !
- mardifoufs 2y ago
  Yes but usually listings that ask for interac e-transfers are a scam in the first place! They are basically impossible to revert to scammers really like them. So even if they had access to interact transfers, they probably shouldn't have bought the listed item anyways.

markus_zhang 2y ago

> Sun’s bootloader environment from that period was called OpenBoot, and consisted of a FORTH interpreter, from which you can interrogate the device tree and pretty much do whatever you want. This sounds interesting. I have read quite a few FORTH posts on HN but never gave the thing a look. It is really different than anything I have looked at. For example, for functional languages I never got pass Scheme's ' symbol, but at least I get most of the syntax. FORTH really is another level.

eschaton 2y ago
This was the basis for IEEE-1275 Open Firmware, which nobody uses any more but was the standard for SPARC, PowerPC, and post-PowerPC POWER. It’s where device trees came from and frankly is how everything should be booting these days, not u-boot or UEFI or custom secure boot chains (which are entirely possible with Open Firmware too). There are BSD, GPL, and other Open Source variants of Open Firmware you can get and fool around with today and if you’re building a new product you should still consider whether an Open Firmware would work for you versus one of its inferior successors.
DonHopkins 2y ago
https://news.ycombinator.com/item?id=33681531 https://news.ycombinator.com/item?id=33681531 I've frequently written about Mitch Bradley's Forthmacs / Sun Forth / CForth / OpenBoot / OpenFirmware on HN. I was his summer intern at Sun in 1987, and used his Forth systems in many projects! [...] https://news.ycombinator.com/item?id=29261810 https://news.ycombinator.com/item?id=29261810 Speaking of Forth experts -- there's Mitch Bradley, who created OpenFirmware: [...] Here's the interview with Mitch Bradley saved on archive.org: https://web.archive.org/web/20120118132847/http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmware-olpc/ https://web.archive.org/web/20120118132847/http://howsoftwar... I've previously posted some stuff about Mitch Bradley -- I have used various versions of his ForthMacs / CForth / OpenFirmware systems, and I was his summer intern at Sun in '87! Mitch is an EXTREMELY productive FORTH programmer! He explains that FORTH is a "Glass Box": you just have to memorize its relatively simple set of standard words, and then you can have a complete understanding and full visibility into exactly how every part of the system works: there is no mysterious "magic", you can grok and extend every part of the system all the way down to the metal. It's especially nice when you have a good decompiler / dissassembler ("SEE") like ForthMacs, CForth, and OpenFirmware do. https://news.ycombinator.com/item?id=9271644 https://news.ycombinator.com/item?id=9271644 [...] https://news.ycombinator.com/item?id=38689282 https://news.ycombinator.com/item?id=38689282 Mitch Bradley came up with a nice way to refactor the Forth compiler/interpreter and control structures, so that you could use them immediately at top level! Traditional FORTHs only let you use IF, DO, WHILE, etc in : definitions, but they work fine at top level in Mitch's Forths (including CForth and Open Firmware). [...] https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/cforth https://github.com/MitchBradley/cforth

neilv 2y ago

> Hard as it may be to imagine, there was a time when Java was brand new and exciting. Long before it became the vast clunky back-end leviathan it is today, it was going to be the ubiquitous graphical platform that would be used on everything from cell phones to supercomputers: write once, run anywhere. > Initially I drank the kool-aid and was thrilled about this new “modern” language that was going to take over the world, and drooled at the notion of Java-based computers, containing Java chips that could run java byte-code as their native machine code. Exactly. I was lucky to see Java when it was still called Oak, and then I developed some of the first (non-animation) Java applets and small desktop applications outside of Sun/JavaSoft. It was very exciting (speaking as a programmer in C, C++, Smalltalk, a little Self, a little Lisp, and other languages at the time). The language itself wasn't as cool as Lisp or Smalltalk, but it was a nice halfway compromise from C++, with some of its own less exotic but nice features and ergonomics. It was already in the browsers, had next-gen embedded systems for the Internet at the forefront from the beginning, there was a proof-of-concept of a better kind of Web browser using it, Sun putting even putting it in rings for ubiquitous computing, there were thin clients that could get interesting (combined with Sun's "The Network Is The Computer", even if historically techies didn't like underpowered diskless workstations, except to give to non-techies), etc., and it only promised to get better... Then I turned my back for a sec., and the next time I looked, Java had been kicked out of the browser, and most all of the energy (except for the Android gambit) seemed to be focused on pitching Java for corporate internal software development. And suddenly no one else seemed to want to touch it, even if there wasn't much better. (Python, for example, from the same era, was one person's simplified end user extension language; and not intended for application development.) Yet another case of technology adoption not going how you'd initially think it would.

markus_zhang 2y ago
I'm curious about what happened. IIRC, as you mentioned too in your reply, that Java was supposed to run in embedded devices. It was supposed to be lean and fast. But I can't imagine the modern Java doing that...
- toast0 2y ago

yjftsjthsd-h 2y ago

Odd that it uses RARP to get an IP but then uses DHCP for NFS configuration. (Or is it the baked in firmware using RARP and then the modern NetBSD kernel using DHCP? That would make more sense) Also: > You need to rename the file with a specific format: the IP address of the JavaStation, but in 8 capitalized hex digits, followed a dot, and then the architecture (in this case “SUN4M”). So, in this example the IP address (as defined in rarpd above) is 192.168.128.45, which in hex is C0A8802D. This is of course the correct way to do it, but if you're lazy you can just tail the tftpd logs and see what filename it tries to download, rename the file on the server, and reboot again to pick it up. (I did this when netbooting raspberry pis)

toast0 2y ago
> Or is it the baked in firmware using RARP and then the modern NetBSD kernel using DHCP? That would make more sense Yes, firmware only knows how to use rarp and tftp to fetch a kernel or a better bootloader, kernel is modern and speaks DHCP. This is a pretty common pattern with netbooting; some will bootp rather than rarp, sometimes you use tftp to fetch something that can do an http fetch, etc. Always lots of fun :D
- eb0la 2y ago
  A lot of old hardware uses TFTP and RARP to boot. RARP just will get you the ip address, and the rest is hardcoded somehow in the machine - needs very little memory on boot. For BOOTP you need some intelligence to know where are your files. TFTP is also cheap in memory to use. UDP without flow, no nothing. Just send me the next packet in sequence when I ask you to do so. I remember having trouble some years ago upgrading old Cisco routers because the image was bigger than what TFTP can handle.

ephaeton 2y ago

I dearly remember setting up NetBSD on various sparc stations and ultra sparcs (a II, and an Ultra 60) and running them alongside a set of various other RISCs and CISCs of late 90s. Based on the paper 'attack of the lemmings' (IIRC) by matthias something (IIRC), I wanted to create a 'how to portably code C' course that would run with just the basic netbsd tools - compiler, editor, test system, make, ... - write once, commit, have the whole weird-ass machine park response to the unit test for a given exercise. Sadly never made it happen fully. Still - NetBSD! fun times, great documentation and such a knowledgeable crowd! Enjoy the voyage!

chasil 2y ago
I am assuming that the major reason that you wanted to do this is that SPARC is big-endian. It works in the native order of TCP/IP, and the hton/ntoh macros are null at the socket level in C. NetBSD can run Raspberry Pis big-endian. This is a much easier platform to obtain and configure than SPARC. The targets appear to be earmv7hfeb and aarch64eb. https://wiki.netbsd.org/ports/evbarm/ https://wiki.netbsd.org/ports/evbarm/
- ephaeton 2y ago
  yeah, machines of different endianness, and, ideally, different alignment requirements. Always wanted to get an alpha, as well. Had hpux / hp300 ?, sparc, sparc64, 386, x86_64, maybe another arch. This was in 2005'ish, mind you. Idea was to write code that would portably work on linux and netbsd on at least said architectures, ideally more.
- DonHopkins 2y ago
  I has having lunch with some hardware designers from SGI and Sun, and the SGI people mentioned jokingly that the MIPS could be both big-endian and little-endian, which they called SPIM. Then they pointed out much to the embarrassment of the Sun people (including me at the time) that the little-endian version of the SPARC would be called CRAPS.

dehrmann 2y ago

> Java chips that could run java byte-code as their native machine code. Hah! Even ISAs are somewhat detached from truly native machine code, these days.

deadlyllama 2y ago

I remember when Java was exciting. There were several attempts at open source Java OSes like JOS (https://jos.sourceforge.net/ https://jos.sourceforge.net/). A Java applet runtime for the PalmPilot. My thesis on dynamic aliasing protection was based on a dynamic Java-esque runtime. But... Java got a reputation for being heavyweight. And yes, as others have said, instead we got the modern web, with (for example) web based word processors requiring orders of magnitude more compute power than a desktop of the early Java era.

pjmlp 2y ago
Don't forget Electron mess.
okeuro49 2y ago
I can remember trying to run applets on a consumer machine. It wasn't a good experience. In the meantime, computers became fast enough to run the modern web. The average phone can run tens of these web based wordpressors.
- jeroenhd 2y ago
  Web applets were a terrible experience all round. Downloaded JAR files usually just worked, though. The GUI looked odd because it wasn't using normal operating system controls, but in terms of performance it was no slower than any native program except for in the most extreme cases. Java on the web was pretty terrible from beginning to end, but The Java Web could've worked. Now that we have the web, we're moving back to the Javaverse in the form of apps (which, on Android, are actually Java(-like)). Every big website has one of those "for the full experience, download our app" banners. Other sites use WASM to bring back the Java applet days, now without third party plugin full of security holes. Google Docs renders to a virtual canvas in the browser in the same way an applet would've back in 2003, except it would've been able to open files directly from the file system. And lo and behold, the new system is also a terrible experience.
  - mark_undoio 2y ago

torcete 2y ago

I remember doing this when I was working for Sun Microsystems. We had to install Solaris in a quite large number of Sun computer for a big client and we did all of them with tftp.

bayindirh 2y ago
Big fleets are still installed with TFTP + HTTP/FTP.
- torcete 2y ago
  I had no idea. Interesting and cool at the same time!
  - bayindirh 2y ago
    It's very cool. Getting a couple racks of new servers and installing all of them from your desk without any interaction is very enjoyable. I also love installing/cabling servers, but not needing to leave your desk to (re)provision hardware is pretty life changing. Considering your desk can be anywhere around the world due to work travels.
DonHopkins 2y ago
Are you the poor Unix system administrator at Sun with the Worst Job in the World, who had to install Solaris on Scott McNealy's and Ed Zander's and other VP's workstations? The Worst Job in the World, from Michael Tiemann <tiemann@cygnus.com>: https://www.donhopkins.com/home/catalog/unix-haters/slowlaris/worst-job.html https://www.donhopkins.com/home/catalog/unix-haters/slowlari... PS: Fuck Trump supporting anti-vaxer Scott "You have zero privacy, get over it" McNealy. May he run Solaris in hell. If you installed it on him, then good for you, he deserved it! Scott McNealy has long been one of Trump’s few friends in Silicon Valley: https://www.sfchronicle.com/politics/article/Scott-McNealy-has-long-been-one-of-Trump-s-few-14447197.php https://www.sfchronicle.com/politics/article/Scott-McNealy-h... Former Sun Micro CEO Scott McNealy, known for his provocative quotes, says Trump is doing a 'spectacular job' amid the coronavirus crisis. That's not how many tech experts see it: https://www.businessinsider.com/scott-mcnealy-praises-trumps-handling-of-coronavirus-crisis-2020-3?international=true&r=US&IR=T https://www.businessinsider.com/scott-mcnealy-praises-trumps... Sun on Privacy: "Get Over It": https://www.wired.com/1999/01/sun-on-privacy-get-over-it/ https://www.wired.com/1999/01/sun-on-privacy-get-over-it/

hiAndrewQuinn 2y ago

>The Java-chip thing proved more difficult to realize than anticipated I've been very slowly upping my Java-fu over the past year or so to crack into the IC market here in the Nordics. Naturally I started by investigating the JVM and its bytecode in some detail. It may surprise a lot of people to know that the JVM's bytecode is actually very, very much not cleanly mappable back to a normal processor's instruction set. My very coarse-grained understanding is: If you really want to "write once, run anywhere", and you want to support more platforms than you can count on one hand, you eventually kind of need something like a VM somewhere in the mix just to control complexity. Even moreso if you want to compile once, run anywhere. We're using VM here in the technical sense, not in the Virtualbox one - SQLite implements a VM under the hood for partly the same reason. It just smooths out the cross-compilation and cross-execution story a lot, for a lot of reasons. More formally: A SQLite database is actually a big blob of bytecode which gets run atop the Virtual DataBase Engine (VDBE). If you implement a VDBE on a given platform, you can copy any SQLite database file over and then interact with it with that platform's `sqlite3`, no matter which platform it was originally built on. Sound familiar? It's rather like the JVM and JAR files, right? Once you're already down that route, you might decide to do things like implement things like automatic memory management at the VM level, even though no common hardware processor I know has a native instruction set that reads "add, multiply, jump, traverse our object structure and figure out what we can get rid of". VDBE pulls this kind of hat trick too with its own bytecode, which is why we similarly probably won't ever see big hunking lumps of silicon running SQLiteOS on the bare metal, even if there would be theoretical performance enhancements thataways. (I greatly welcome corrections to the above. Built-for-purpose VMs of the kind I describe above are fascinating beasts and they make me wish I did a CS degree instead of an EE one sometimes.)

jraph 2y ago
> It may surprise a lot of people to know that the JVM's bytecode is actually very, very much not cleanly mappable back to a normal processor's machine code or instruction set I believe this is a very sensible decision: being too close to a real architecture would probably tie the bytecode to similar architectures too much and make it quite useless as opposed to compiling to an actual architecture. The bytecode being abstract enough is likely a good thing to be able to achieve okay performance everywhere. Like, you wouldn't want the bytecode to specify a fixed number of registers. What may also surprise many people thinking Java is a bloated language is that the Java bytecode is actually quite simple, straightforward to understand, clean and also very well documented. It's an interesting thing to look into, even for someone not involved day to day in some Java.

chasil 2y ago

"Thankfully, despite its age and total lack of security, NFS is still well supported under Linux." NFSv4 can run over TCP, which means that any encrypted wrapper can carry it. While SSH port forwarding can be used, stunnel is a better fit for batch environments. Wireguard is another option from this perspective. Encrypted ONC RPC works at a lower level of the protocol to secure NFS, which is documented in RFC-9289. Obviously, none of this will help with a machine using RARP and TFTP over 10baseT.

DonHopkins 2y ago
NFS originally stood for "No File Security". https://news.ycombinator.com/item?id=33384073 https://news.ycombinator.com/item?id=33384073 Speaking of YP (which I always thought sounded like a brand of moist baby poop towelettes), BSD, wildcard groups, SunRPC, and Sun's ingenuous networking and security and remote procedure call infrastructure, who remembers Jordan Hubbard's infamous rwall incident on March 31, 1987? https://news.ycombinator.com/item?id=31822138 https://news.ycombinator.com/item?id=31822138
- EvanAnderson 2y ago
  > NFS originally stood for "No File Security" I often heard a different "F" word in that acronym in place of "File".

tomaytotomato 2y ago

MisterTea 2y ago
> write once, run anywhere. Was such a great promise. I remember visiting PCExpo in the late 90's and Sun's booth had a Java demo running on three machines: Linux x86, Windows X86 and Solaris Sparc (OSX wasn't even revealed yet). You could run a few demos you selected from a menu one of which was a 3D ship with accelerated OpenGL which really thrilled me - cross platform everything, even CAD and gaming. Amazing! The future is finally here. And it never happened. Bummer. Instead we got a badly hacked up hypertext viewer with various VM's duck taped to the sides.
seabrookmx 2y ago
I don't think the comparison is new Java to old Java, I think it's Java vs. it's competitors. When Java was new, scripting/dynamic languages hadn't matured enough to be true competitors so you were left with C/C++, Delphi and the like. In that landscape, Java is beyond exciting. Nowadays there are so many alternatives that didn't exist then. And it's not debatable that many of those languages (Dart, C#, Typescript, Kotlin) move faster when it comes to language features. Whether you want/need them is subjective, sure. But back in the day Java was that hot, fast moving language.