TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

NetBSD on a JavaStation

166 点作者 jaypatelani2 个月前

11 条评论

deadlyllama2 个月前
I remember when Java was exciting. There were several attempts at open source Java OSes like JOS (<a href="https:&#x2F;&#x2F;jos.sourceforge.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jos.sourceforge.net&#x2F;</a>). 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.<p>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.
评论 #43264276 未加载
评论 #43269082 未加载
评论 #43264244 未加载
dleslie2 个月前
&gt; 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.<p>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.<p>Always ensure the product exists, or the service is rendered, before using Interac E-transfer.<p><a href="https:&#x2F;&#x2F;www.getcybersafe.gc.ca&#x2F;en&#x2F;e-transfer-fraud-protect-your-online-transactions" rel="nofollow">https:&#x2F;&#x2F;www.getcybersafe.gc.ca&#x2F;en&#x2F;e-transfer-fraud-protect-y...</a>
评论 #43262656 未加载
评论 #43265284 未加载
chasil2 个月前
&quot;Thankfully, despite its age and total lack of security, NFS is still well supported under Linux.&quot;<p>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.<p>Encrypted ONC RPC works at a lower level of the protocol to secure NFS, which is documented in RFC-9289.<p>Obviously, none of this will help with a machine using RARP and TFTP over 10baseT.
评论 #43266717 未加载
ephaeton2 个月前
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 &#x27;attack of the lemmings&#x27; (IIRC) by matthias something (IIRC), I wanted to create a &#x27;how to portably code C&#x27; 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!
评论 #43265770 未加载
hiAndrewQuinn2 个月前
&gt;The Java-chip thing proved more difficult to realize than anticipated<p>I&#x27;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&#x27;s bytecode is actually very, very much not cleanly mappable back to a normal processor&#x27;s instruction set.<p>My very coarse-grained understanding is: If you really want to &quot;write once, run anywhere&quot;, 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 <i>compile</i> once, run anywhere. We&#x27;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.<p>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 <i>any</i> SQLite database file over and then interact with it with that platform&#x27;s `sqlite3`, no matter which platform it was originally built on. Sound familiar? It&#x27;s rather like the JVM and JAR files, right?<p>Once you&#x27;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 &quot;add, multiply, jump, traverse our object structure and figure out what we can get rid of&quot;. VDBE pulls this kind of hat trick too with its own bytecode, which is why we similarly probably won&#x27;t ever see big hunking lumps of silicon running SQLiteOS on the bare metal, even if there would be theoretical performance enhancements thataways.<p>(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.)
评论 #43266107 未加载
评论 #43265801 未加载
评论 #43268869 未加载
评论 #43268524 未加载
评论 #43266419 未加载
tomaytotomato2 个月前
&gt; 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.<p>As someone who started their software career at Java version 8, I wouldn&#x27;t say the trend in Java has been to become more clunky.<p>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.<p>For frameworks we have Spring Boot, which can be as clunky or as thin as you want for a backend.<p>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.<p>Maybe the author is nostalgic for a time (which I didn&#x27;t experience - was busy learning how to walk), but Java can do all the things JDK version 1 can, and so much more. No?
评论 #43271682 未加载
评论 #43273783 未加载
markus_zhang2 个月前
&gt; 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.<p>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&#x27;s &#x27; symbol, but at least I get most of the syntax. FORTH really is another level.
评论 #43263446 未加载
评论 #43271764 未加载
评论 #43266724 未加载
yjftsjthsd-h2 个月前
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)<p>Also:<p>&gt; 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.<p>This is of course the correct way to do it, but if you&#x27;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)
评论 #43263355 未加载
torcete2 个月前
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.
评论 #43264867 未加载
评论 #43270028 未加载
neilv2 个月前
&gt; <i>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.</i><p>&gt; <i>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.</i><p>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&#x2F;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&#x27;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&#x27;s &quot;The Network Is The Computer&quot;, even if historically techies didn&#x27;t like underpowered diskless workstations, except to give to non-techies), etc., and it only promised to get better...<p>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&#x27;t much better. (Python, for example, from the same era, was one person&#x27;s simplified <i>end user extension</i> language; and not intended for application development.)<p>Yet another case of technology adoption not going how you&#x27;d initially think it would.
评论 #43262804 未加载
评论 #43263586 未加载
dehrmann2 个月前
&gt; Java chips that could run java byte-code as their native machine code.<p>Hah! Even ISAs are somewhat detached from truly native machine code, these days.