I looked into it once, I think the script or system that built the larger dumps broke and no one fixed it. I started working on it but other stuff got in the way.
I've seen the XB-70 at the Dayton Air Force Museum and each time it seems both massive and relatively svelte. Like some kind of shape that I can't quite fully understand. Really cool plane to see, especially among all the other aircraft from that era of aviation.
> The answer goes back to the early 1990s, when the Internet existed – but the World Wide Web did not. NASA was on the Net very early in its history, and the nasa.gov Domain Name Servers (DNS) – the Internet's version of a phone book (OK, online directory) – handled bulletin board systems, Gopher and more. When the World Wide Web came along, www.nasa.gov became the agency's primary home online.
> Today the World Wide Web is still one of the many, many networked services NASA provides, all based on the nasa.gov ___domain. But along the way the web became the public's most widely used aspect of the Internet, so much that the "www" became almost implicit. It started to disappear from the URLs of popular websites. NASA never made that switch, and our ___domain servers still do not forward users looking for nasa.gov to www.nasa.gov. (Though many web browsers now do that automatically once you've visited a site.)
Looks like FAA might still be that way, or the changes are still rolling out.
One reason some sites used to be stuck with this configuration is that you can CNAME a www subdomain to a CDN but you can't CNAME your eTLD+1 without also affecting your other records (MX/etc).
There have been various solutions to this problem like ALIAS records, but perhaps they never upgraded.
That hasn't been my experience at large corporations. They usually have a corporate proxy which only speaks HTTP 1.1, intercepts all HTTPS, and doesn't support websockets (unless you ask for an exception) and other more modern HTTP features.
I worked with a team of developers tasked with creating a few 100% static websites. Single page, no interactivity, nothing dynamic. They were talking about which React components to use, server APIs to build, etc when I asked why they didn't just write HTML or use a static site generator and host the page in S3. They didn't know how to write vanilla HTML, they had never used it for more than bootstrapping a React app.
I'm still fascinated by a website linked on HN some time ago that was written in MarkDown, but then not translated to HTML and served, but sent as MarkDown along with a JavaScript renderer that would then translate and render it on the client. Sure, it works, but why?
(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
mdwiki.info? I wrote it because back in 2012 you had a "Public" folder in Dropbox that also was a public static web space. So a way to create a homepage without installing any software and without need to learn html.
Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.
These laptops had <1gb RAM. You should be amazed if you could open multiple website.
Each website is essentially a full program with sandboxing etc - and surely you'd be aware that opening I.e. Photoshop 4 times on such a resource restricted system would be just as impossible.
And it wasn't any different back then. At last not on Mac, as I had an iMac and vividly remember the same issue.
The last devices before they switched to Intel had pretty bad performance, that was the reason why they switched soon after.
Writing good HTML is not what employers, hiring managers, HR, and resume algorithms consider to be a skill worth paying for. You gotta know React or GTFO. From the perspective of a newbie developer, why waste time learning the grandpa way of making webpages when React can do all the things?
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
Yes, but remember: static HTML is a one-way street. Better tell your manager otherwise they will one day come up with functionality that can't be done in your website and it's your fault.
EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.
You can make an example that will invalidate any technology choice. Design for the requirements you have.
"That's a very nice car you've made. Unfortunately, if the designer later decides that it needs to survive artillery rounds, you'll wish you had built it out of armor steel as I recommended in the first place."
On the outside of their eyelids it would do nothing for self-awareness, so I'm assuming written on the inside... which they won't be able to see unless they look at something super bright, like the sun, with their eyes closed.
... I guess this season some of us have more time to overthink things.
Still, YAGNI needs careful consideration. What looks like YAGNI right now might be reasonable flexibility that will be needed as the project matures. YAGNI makes perfect sense when delivering a proof of concept, but it's not that straightforward when designing for long-term use.
The parent comment is a bit exaggerated but it still has a point. One needs to be able to predict things and make sure whatever you do today isn't so rigid that it can't adapt to other things in the future without a major overhaul. Typically this means being cognizant of the assumptions made along the way, and making the minimal set of them. This kind of insight requires experience. People preaching YAGNI just don't seem to have much of it. They just read "YAGNI" in a blog post and then yell it at other people.
I agree no one should follow recommendations blindy, but I have seen WAY more instances (firsthand and second-hand) of people mis-architecting for circumstances that never come.
When it comes time to make a change, it's often not as big a deal as it was made out to be, and you have the benefit of everything that has been learned along the way. No one gets it right the first time anyway, so don't overthink it.
There are plenty of things you can do with static websites, especially given you can have site generators and/or can write javascript by hand too (shock!).
For example if the requirement is to have website editable by non-programmers, that's where static site generators shine. Sure, one has to press "deploy" button and wait a minute before changes are visible... but you get to keep all the features of static pages, like trivial scalability and very high security and availability.
Even if you have to have dynamic functionality (like a shopping cart), there is no need to do the whole website dynamically. Sure, have an API server which may even render the cart page, but the rest of the website can be fully static, maybe with a tiny bit of javascript to render the "number of items in the cart" icon.
Absolutely. I built something like that during high school for a local artist. Had and interactive backend that allowed him to upload his creations and it would regenerate static HTML when he was done with that. That was my first paid developer job basically.
I re-used it later on in university to hand it in as a project (easiest course ever) and got commended for not putting load on the servers and making the site slow for users by using something like PHP to re-generate the same stuff over and over as users browsed the site. A+
This would maybe be a few hours of work if going from a static site to a SPA was actually in scope. Strip headers from the current pages and now serve the body as content from an API.
You don't need your entire site to be built with react to use react within your site and building a JS based router is not very difficult and will get even easier if the Navigation API[1] becomes better supported.
This would actually be harder if you now still need a static site with an across page assistant. I would probably push back on some requirements and store state locally in the browser. Effectively hot reload the assistant on each navigation but even then it's doable, even using react.
You can develop that element and then just drop that onto your static page via /assets/ and you're golden. Easy to develop, simple to deploy and tiny file size.
You absolutely can, but it's way more common to only know how to create a blank site with a framework than to migrate an existing site. React used to have a section in its documentation for how to add it to your site without adding a build system (not common knowledge, unless it's setting up a blank site through a script) and they've since replaced it with a brief tutorial telling you to migrate your website to a JS module with a link to a suggested build system.
All of this matters because the person that has to do this setup might not be you. It's certainly a problem with the frameworks themselves that porting a website (even just to add a little functionality) isn't as easy as setting one up initially but there's not really much an individual can do here. It's one reason I like frameworks like Preact so much, they're actually trying to fix this.
Are these frameworks incapable of having the static content as something that can be served? Are the links in the existing content unable to be updated to whatever need to happen for the page transitions?
I was going to say the same, I have a webxr (virtual reality) site that has a few react components on it, plus a few vanilla javascript libraries in the main page template.
Umm, how is it a one way street? Just add a <script> tag and implement what you need... I'm not 100% convinced that using react from jump street "Just in case we need something in the future" is a great idea. That having been said, I'm not sure I've built a completely static html page in the last decade.... So I often start with react/angular.
It's frustrating the lack of simple tooling out there for static site generation. I have had to write bespoke static site generator build scripts just to get things working.
Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.
Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.
Ok so just a warpd/keynav style grid mode then? I thought OP was describing a novel concept based on the idea that initially the whole keyboard would represent the entire screen.
Yeah, "Grid Mode" sounds similar. But instead of only 4 zones it would just roughly map the keyboard to dozens of invisible zones based on the position of the keys on the keyboard. So it would mostly be by feel. I have no idea if this would be better or worse than "Grid Mode" but it would be interesting to try it.
I recently got into Parks on the Air, where you go to parks with radio equipment and try to make 10 contacts. It's fun, gets me out of the house and can be an interesting challenge depending on atmospheric conditions. I built a small kit radio (https://qrp-labs.com/qmx.html) for use when visiting some of the parks that have longer hikes to interesting areas. Building the radio was a great lesson in electronics and exposed how horrible my soldering skills were. My curiosity about how the SDR stuff worked, especially the transmitting side, led me to reading lots of great posts and information about RF, modulation, etc.
The emergency preparedness side of things is an important side of amateur radio, but learning is an equally if not larger part of it.
Can relate with the learning part as the motivator. I would like to know whether you needed anything special for building the kit like e.g. an oscilloscope or other expensive instruments?
A good soldering iron, a magnifying glass (I have an articulating lamp with a built-in magnifying glass) and a basic multimeter is all that’s needed, but a clamp or “helping hands” to hold the circuit board would be helpful.
I miss Sun hardware, especially in the sun4c era. Everything was so solidly built and well thought out compared to a lot of PC hardware. The IPC/IPX is still one of my favorite form factors.
I still have an IPC on my desk as a monitor stand. In 1996 I used it as a router for my 24hour 56kbps modem connection, serving all of 204.94.173.x - I was paying tlg.org $145/mo for my Class C address space, and all my home machines were just hanging out there. that is the internet I really miss.
I have been thinking about getting an old IPC or IPX and swapping out the internals with a modern PC motherboard and components, but only if I can do it cleanly. I haven't done it due to not having enough free time and... it just feels wrong to me in some way.
Ah the trouble of finding a unix workstation with a pristine case and thoroughly cooked interior so you don't feel bad about gutting it for a casemod. Call me when you find one.
Same! My IPC served my ___domain using Solaris on a nailed up bonded ISDN circuit until someone filled the root disk trying to patch the rpc.cmsd remote exploit. After that it was BSDs until I settled on OpenBSD.
Ditto here. I loved their hardware from that era up until the early 2000s. I still have a few dozen systems from those years in my basement. I tried getting rid of them years ago using the Marie Kondo method, but they all SPARC joy...
I can remember carrying a Sun machine around for demos in '95 or so - the IPX was easy to carry but the monitor less than easy. What I particularly remember is getting the occasional electric shocks from the monitor when carrying it (presumably from energy stored in capacitors) and being really careful not to drop it as our two person company only had one Sun monitor!
I greatly enjoy the Sun3 and Sun4c/Sun4m era, always under SunOS 4. Probably because that's what I started on with my first UNIX account (Grex). Probably why I still prefer the BSD-style distros nowadays.
reply