He checks the Referer header[1]. In Firefox you can prevent that header from being sent by setting `network.http.sendRefererHeader` to 0 (in about:config).
That is the way it was done back in the day, usually when admin wanted guests to not come through Google Search or to come through a correct word-of-mouth bouncer page. Client side JS implementations allow content to be viewed by blocking JS.
Enclosure at small scale can be 3D printed. Use FDM for mechanical fitment checks, then make in SLA resin printers for first couple clear case prototypes. I wish I could do keyboard as easy...
RaSCSI is a virtual SCSI device emulator that runs on a Raspberry Pi. It runs in userspace, and can emulate several SCSI devices at one time. There is a control interface to attach / detach drives during runtime, as well as insert and eject removable media. This project is aimed at users of vintage Macintosh computers from the 1980's and 1990's.
It's aimed at vintage Macintosh, but wouldn't it work with any old computer using SCSI?
I have an HP machine that I would be happy to resuscitate with a new install of HP-UX, but its CD drive is dead.
What are you going to do about the actual cost of the device? You've already got an e-paper display, but you're also adding a 'laptop' style enclosure, real keyboard, and if you're storing SSH keys, you're really close to running a cut-down Linux system. That's basically a laptop, and you could get the same thing with, you know, a laptop. Have you thought about scaling down the display, keyboard, and enclosure to something palm-top sized?
That is very cool! Have you built a physical copy of it?
No, I think the smaller size is probably a non-starter for the intended audience. This is meant to be a tool that a lot of these folks are using for hours and hours a day so overall typing and reading experience is paramount, and meant to be a "selling" point.
Cost-wise, yes--we're still grappling with costs of the e-ink screen. It's the by far the largest expense in the unit. We've got a good lead that I unfortunately can't talk about at the moment (under NDA).
A cut-down Linux really is overkill for this, and isn't capable of making some of the other specs happen (battery life, availability), at least as far as we've been able to determine. Custom code is unfortunately where we've been forced to go.
The other reason not to run Linux is because the ESP32's a bit underpowered to run Linux (lacks an MMU). Slightly more powerful hardware (eg Raspberry Pi Zero) would do better, and get you a working device far sooner, which would be great for testing out some of the other components while waiting for getting the software written.
Embedded Linux (eg any distro using busybox for glibc) is (imo) the appropriate stack to use for this given how cheap a microcontroller with an MMU is these days, and once you get rid of all the bloat, is capable of very quick boot times (availability), and if the device is off (and not just sleeping), then its battery life is similarly extended. (Don't let the poor battery life of Android phones let you believe Linux isn't capable of long battery life. Smartphones don't actually get to sleep while the screen is off.)
The ESP32 is getting replaced with a better microcontroller (it's down to either an upcoming STM32 ultra-low power or the upcoming Ambiq Apollo4 depending on how well they perform in real life), but ESP32 was what we started with given familiarity and availability.
Remember, the device can sometimes have enough time to sleep BETWEEN keystrokes while typing. (The microcontroller can sleep then wake and power up peripherals with only a tiny, imperceptible delay.) This isn't your typical Linux setup. FreeRTOS is plenty. For the limited things it does, it wants to be a no-compromise device. There is no on button. There is no off button. You grab the device, it has an image on the display because it's e-ink and you start typing. Assuming you've previously connected to a remote device the system will have done what's necessary to keep that connection alive (invisibly waking as needed). Your keystrokes can go through right away to the remote connection. Your results will hit the screen right away too. The device is always on and it is always off, if that makes sense. There's more to it--bits of stuff and bother and implementation details--but I hope this gives you the idea.
Honestly, 13" is more than you need for a 4:3 terminal. A lot of classic character terminals had 9 or 10 inch screens...it's not until you get to like the VT320 that you have a 14" screen. I'd consider a 10 inch screen about ideal, and the keyboard doesn't have to be 13", either.
We are making prototypes in 3 different 4:3 sizes--10.3, 12.1, and 13.3. 13.3 is furthest along. The end of your comment talks about the real size restriction for us--keyboard. We do not want to compromise the typing experience.
Around 12" (in a 4:3 body) is about as low as you can go without messing with the typing experience much. The problem at that size is the available e-ink panels are S-L-O-W; no fast refresh models are out there.
(You might ask why we would even do the 10.3" prototype if we know that's too small for keyboard reasons? It's mostly for marketing reasons when we actually try to try to get attention for this project. The 10.3 is going to use a Thinkpad 701c butterfly keyboard in a custom body just for the "wow!" factor in showing the sorts of things that are possible. The 10.3 would actually be a killer end-product, but no similar keyboard is in current production so we couldn't actually make it).
Have you considered using a DES display or Sharp Memory LCD? I know the first is definitely cheaper than a branded E-Ink display, and the latter has much faster refresh rate and may be more suited to being a terminal (and may also be cheaper than E-Ink, I just haven't looked into it).
Yes we have considered it. Do you know of any such large (over 12 inches) panels with decent resolution and pretty fast updates that are available? Such a thing would probably help with power consumption. (e-inks consume a lot of power during screen updates).
Looking at all of the options a simple full RLCD would probably be best for us--not eink--but we can't find appropriate parts for the size and resolution.
I know that the DES displays go up to 10.1", but I haven't seen displays beyond that size (though I'm unsure if they intend to make larger displays in the future). For the Sharp Memory Displays, I think I may have spoken too soon - looks like they top out at 4.4" currently, which of course wouldn't work for your application.
RLCD is an interesting option, I guess the sacrifice there is readability angles and paper-like-ness?
Ones with good viewing angles exist, but for sure there isn't paper-like-ness and you loose the no zero-power persistence of e-ink. But you get fast, artifact-free refreshes, perfect sunlight readability, at very low power consumption. (No backlight which can be a pro and a con...if only a more modern Pixel Qi type panel existed.)
If you're shocked by this, you would be appalled at the state of Open Source Hardware.
I've gone over the OSHWA Certified Project list [1], go into the repos, and actually take a look at what these projects offer. The _majority_ of projects only include a schematic PDF, which by OP's own assertion is not Open Source. If you find some mechanical bits of projects, you'll find some Solidworks files, too -- good luck opening that without calling a Dassault sales rep. And of course there are the projects where the links to project files are just dead. Only about 50% of OSHWA-certified are editable in any software.
Unsurprisingly, one of the best contributors to OSHWA-certified projects is Adafruit, with Sparkfun close behind. Everything is just there (needs a bit more organization, imho), sitting in a Github. Almost everything is in Eagle, though, which is non-free and sure to annoy some Open Source advocates.
There are a few theories on why this is, most notably that 'Open Source' is a replacement for the cost sink of producing real documentation. The fact that companies (Adafruit and Sparkfun) are the largest contributors of OSHWA certified hardware supports this.
Schematics only contain a fraction of the information required to reproduce a design. It's like releasing a UML diagram of an app and calling it "open source."
It doesn't matter if you use the same CAD tool or not, there are a variety of utilities for converting the design files. What matters is if you can reproduce and modify the design. That's simply not possible without the complete design files.
You don't release the artifacts of your compiled code and call it open source. You release all the source required to generate those artifacts. Anything short of that is not open and fundamentally mistakes what it means for something to be "open source."
> Schematics only contain a fraction of the information required to reproduce a design. It's like releasing a UML diagram of an app and calling it "open source."
A good schematics is all you need. (it must have components values). The rest (layout, analysis) you can do it yourself.
> It doesn't matter if you use the same CAD tool or not, there are a variety of utilities for converting the design files. What matters is if you can reproduce and modify the design. That's simply not possible without the complete design files.
Well, it's a bit different from SW. Schematics is some kind of source code and the layout is a kind of compiled code. Different layouters will produce different layouts.
And when you modify the design you have to redo the circuit analysis and , maybe, the layout .
> You don't release the artifacts of your compiled code and call it open source. You release all the source required to generate those artifacts. Anything short of that is not open and fundamentally mistakes what it means for something to be "open source."
You release only your program, not the whole OS. Somedy who wants to "reproduce your design" still needs a compiler and an OS to run it.( and depending on the conpiler it may obtain different results :) )
I disagree, schematics are a form of documentation. They are not a design and they are incredibly leaky.
As an example, it's common to group all the bypass caps together in a schematic. This doesn't reflect the reality that those bypass caps need to be physically close to the power pins on specific components. The value is not sufficient to reflect their use.
It's no different from software engineering, the schematic is not the source code. It's a block diagram describing how the source works.
The "layout you can just do yourself" IMHO very much depends. For simple circuits, yes, for anything involving antennas, high-frequency signals, ... not. And as far as there are standards defining what Open Hardware is, they all consider design to be part of it.
Open Source is when you can compile the provided project given the right tools.
From a Schematic alone you can't send the board to production. You'll need the BOM and the Layout for that.
Also OS encourage patch and contribution, without the layout you can just re-design the entire board from scratch, not doing incremental improvements on the OS version.
This is a great trick, but it's only really useful if you're using a CRT or are on a very memory-constrained platform where you can't store a separate 'bold' font.
I've implemented it here https://twitter.com/ViolenceWorks/status/1387519297262477312 and barring the exception of fiddling around with dotclocks and such, it would be far simpler to have a different 'bold' font. Of course, if you're using a CRT doing this is as easy as 'keep the gun on a bit longer if it's bold'.
This is one of the rare cases where you really get to see the relation of a CRT with the thought of, 'a technology is only perfected after it has been rendered obsolete.'
Fairly easy, a few thousand lines of C. Bit of work, though. Parser is the hardest, a lot of details to get right. You don't really need a buffer for the output, because you can't type that fast.
Of course, driving the display is a bit harder. I'm using a parallel tft, wrote the driver, too. Keyboard code is kludgy because I'm not using diodes for cost reduction on the bom.
You can see it here: violence.works yes that's a url.
I'm both amazed at what you've accomplished and a little miffed that someone beat me to it: I've been working on-and-off on a similar project for a couple of years now haha. Awesome work
What display did you end up settling on, where'd you source it, and how many columns do you end up fitting? That was the biggest sticking point for me.
If you're talking about the recipes, it's open source in that it's public domain. Or it's not open source, because it can't be copyrighted and therefore all the frameworks that allow for open source don't apply. [1]
This is actually _really, really interesting_ and could spur some really great discussion, so I was ready to check out the HN comments only to find... griping about recipe sites. Ctrl+F 'Open Source' to find this comment. Man, HN sucks.
Stop down and take a long exposure. You just want to avoid the focal plane shutter or digital rolling shutter, and capture one beam paint, or lots of beam paints to even out the intensity.
