This would be a great product for a non-profit to improve on. Some of the restrictions (only 7k characters stored, consumption of expensive resources like paper, ink ribbons, correction tape, etc) could be fairly easily and cheaply fixed by making a dedicated word processing machine instead of a typewriter out of something along the lines of a raspberry pi and a cheap low res display. Assuming there's a way to print from USB in prisons, or access to computers with email periodically (big assumptions that I haven't verified beyond what I've seen in popular media) this could provide an affordable lifeline to a lot of people.
Whenever I see people get excited about doing something to help prisoners my heart breaks. The problem is not that we only have 7k to work with. The problem is that they are in prison. We should be directing our energies toward that problem, not this one.
Prison in America has taken over the social function of slavery. I wish there was some way to get people to care more about the issue but the Just World fallacy [0] is an indomitable foe.
You can tackle both. It's usually sane to do so, as short term and long term are complementary, plus people are motivated or gifted to act in one area or the other but not always both.
From what I read, more or less the entire US prison system would be a great product for a non-profit to improve on (food and phone calls are ludicrously expensive, too, for example), but it wouldn't bring in more money, so it won't happen without a huge social backlash against the way the US prison system treats prisoners.
At its roots, this is a social problem, not a technical one.
The phone calls and commissary products are expensive because the contracts revenue share back with the prison. A non profit doesn't solve this issue, as you won't get the contract without juicy kickbacks.
Unfortunately, I bet there are a bunch of regulations, both federal and per state. For example, the 7k memory limit is a state-by-state thing: "Memory sizes greater than those permitted in any specific correctional facility will be rejected at the facility property room" -- from the vendor's website.
Memory size limits... hmmm... text compresses fiercely. 7k only being able to store about 4 pages sounds an awful lot like zero optimization. I think some clever microcode might quadruple this or more.
Same thought. Let's see what that looks like Huffman coded. Or LZW or something. And most importantly, _localized_.
The only technical questions are what defines "memory" (flash vs SRAM?) and whether "memory size" refers to native capacity or compressed capacity. This is a legal problem, not a technical one. But it's probably one that can be solved with a sufficiently-sized ROM that does this stuff internally as a fixed function/trap. Think Mac Old World ROM.
Interesting legal question: if encoding scheme X doesn't code native language Y as well, in a world where people use digital typewriters, is that an equal-protection claim?
Furthermore, do prisoners not have unlimited rights to pen and paper? Is that not an equal-protection claim? Shouldn't they be allowed to possess multiple pads just like with paper? (not with a 5-4 Republican SCOTUS unfortunately)
Localization is not only important for the user base but also sets up the appropriate legal fights. Winnable ones, for this product.
Because in TYOOL 2017, paper = digital. Prisoners have a right to their private legal correspondence even in prison, and have for a long time. The fact that the typewriter is now digital is immaterial and denies prisoners their rights. Eventually we can provide mathematical assurance that the correspondence between prisoner and lawyer is private.
The struggle for developers is to make it sufficiently inert to the point that it is inarguable legally. We want to be able to claim this is a dumb plastic typewriter, but digital.
I presume though, that this limit is the limit of characters stored, not the size of the memory. If you compress, of course you can store the same characters in a smaller amount of memory but that is not going to help the prisoner because the prison won't approve a larger number of characters stored. It likely doesn't help the manufacturers any either, since memory is cheap now.
Its going to be arbitrary, but I understand prison rules often are.
Even with an identical product, the article says that the Swintec is specifically enumerated in many prison regulations. Getting a new item there might require a large licit or illicit sales budget.
I've been mentally designing this idea for literally a decade now, just about exactly. I actually think it can be made quite better than that, at a lower cost. And I think similar to the Raspberry Pi Foundation, public sales could fund philanthropy in a very critical and under-served area. Give it away free as much as possible, otherwise get it into commissaries as cheaply as possible (and lock them down with sales agreements to prevent them from overpricing).
I was really into classic computers as a kid, and one that always fascinated me was the TRS-80 Model 100. It's your basic dumb Z80 computer: it has a 8x40 character display, a keyboard, and... that's it. What made it distinctive is the >20-hour battery life on 4xAA batteries, which is just absurd and still has yet to be matched today. It's minimal and good at what it does - edit text. It edits text. For a really long time, on easy-to-replace batteries.
Well, surely we can do better today? I want the minimum possible programming terminal that's productive, that you can squeeze the maximum amount of battery life from. Yes, from AAs if necessary.
My ideal implementation would be AVR8, AVR32 if necessary. Not only are they dirt cheap but we can clock them down to zilch with PicoPower, to get that battery life. PicoPower is 0.2 mA per MHz at 1.8V, and the <1 uA sleep is literally less than batteries will self-discharge in the box. It runs some thin native-C implementation of a text-editing terminal, and a Wifi connection is used to flush a minimal data stream back to a local server. When you do things like compile or run, or debug, that runs on the host, but you have a thin terminal that continues pulling almost nothing.
Even OLED power draw is nontrivial and it's hard to get OLEDs that are both inexpensive and large enough to be a viable display, so here's the next clever bit. E-ink display. You only use power when you're redrawing it, and you can probably redraw it leisurely at your own pace with a slow MCU. In theory you can reduce refresh speeds even further by only redrawing a section - the downside is you leave a "flipped line" outside the region. Which just looks like notebook lines anyway.
Throw on a good 40% keyboard kit (is there anything that can be bolted down to another board? honest question) and you now have something that's basically a wireless VT100 but can do all your shit, as long as you are comfortable working in a text mode with a limited refresh. This is a workable protocol model - it's already been done! Hell, we have more power than VT100 right in the terminal.
To make it even cheaper you could pick some super common laptop model and use that keyboard socket for your motherboard. Let's say, the old Thinkpad T420 keyboard, which is already knocked off in China like crazy and is good enough to keep alive. Just plug their parts into the board. How much do they cost in quantity 100k? Probably nothing.
I've run this concept past HN a few times before as a programmer terminal and usually gotten a positive response for their own usage (would be good for a dumb serial terminal too) but this could be a philanthropic usage good enough to drive the concept.
The prisoner typewriter is the exact same thing, minus the wifi chip (USB dump only), plus a warden's interface web program to oversee text, plus a clear plastic shell. So just a dumb TRS-80 Model 100 again. And the battery life is an incredible advantage when you have no regular access to a USB port to charge, and you're getting raked over the coals by the commissary. How about 10 hours on a pair of AA batteries, with a reserve AA for SRAM retention, and perhaps a coin battery epoxied on-board as a last resort? I think that should be doable.
I'm actually serious about this, anybody else down? Prisoner's lives are shit, but at least we could keep them from being raked over the coals for literal typewriter supplies in TYOOL 2017.
The big problem would be dealing with the established player in the field who would undoubtedly come down like a ton of bricks. Good luck getting approved in the commissary when you are fighting a state-by-state battle with legislatures against these guys.
Ha, I knew about the AlphaSmart at one point and had totally forgotten it, but that's where I want to go. Totally a great example of a TRS-80 M100 clone. We can do this better now. Cheaper, better, relevant to multiple markets.
The FreeWrite seems conceptually close but misses the mark on a lot of implementation points. Running a Raspberry Pi or whatever is totally unnecessary. So is the realtime Dropbox syncback. Battery life is sacred, bitch.
It's also $500 for a Raspberry Pi in a plastic shell. I want to do an actual Raspberry Pi-style project that can be bought for something perceived as an actual value option in its situation.
Let's engineer a product for this, actually for this, not just "RPi but with XYZ".
People get a few hundred hours of battery life from some models of graphing calculators. The keyboard and displays are a poor fit, but memory and processing power is plenty for a basic word processing.
But, you could take this further and just use some solar cells.
What possible incentive could you give to the people in charge?
Nobody cares about making the prisoners' lives better - the ones that matter are felons who can't vote anyways.
Your value proposition is that you make the prisoners' lives better - how do you demonstrate value to the stakeholders?
More bluntly put, what's the value add to an elected official or a prison warden? I suppose if you did a study in prisons showing that your new device reduced violence and disturbances over the old typewriters, you might have a case.
Otherwise, you cannot convince the people who matter. This is not a tech problem, it's an institutional problem.
why not look at a low travel keyboard and pot the whole damn thing?
[edit:
maybe not jump to putting the warden in the loop. maybe use cf instead?
maybe separable keyboard? a low cost e-book reader is probably pretty useful as well]
]
I fully agree (it's problematic for stuff like legal correspondence) but you know it's going to be Item #1 on any list of criteria for adoption.
Reality is that right now wardens can peek on pretty much what they want. It's paper. Who gets to decide what prisoner letters get opened? The warden.
Stuff that is technically protected correspondence gets opened? Sucks to be you. If it's not a sealed room alone with your lawyer... it counts. Is SCOTUS gonna come down on the guards/warden/etc? Hell no. Lol if you think you can even convict a specific random cop who does a thing. Inmates have basically no legal protection or rights.
In a 5-4 ruling, it's a "bona fide mistake".
Fight that fight later. Because eventually we can actually mathematically guarantee, with encryption, that nobody but the lawyer can actually read that.
I'll second The Art of Unix Programming - despite the title, it has many broad programming and software architecture lessons, and "The Unix Philosophy" is applicable far beyond Unix.
I have a pretty negative opinion on ESR these days. I could find technical arguments about many aspects of his good pieces of writing, and much of his writing is not good. His abilities as a coder are not generally remarkable, either. But mostly I don't think he's a good person. I would probably not say "Don't read ESR", but I think it has to be "Read ESR* "
*but be aware that he's a polarizing figure and opinions of his merits differ
(and if you happen to have a differing opinion, please use the reply button instead of the downvote button)
I share your sceptical opinion about ESR, but I concur with the other commenters that The Art of Unix Programming is still worth reading. (In contrast eg to his thing about Bazaar vs Cathedral.)
The Cathedral and the Bazaar was not an excellent piece of writing, but it was sort of necessary at the time. It has served its evangelical purpose well, to the point where it's no longer necessary. Open Source won the day, in no small part due to ESR. (I think it vital to give my enemies their due praise).
TAoUP is a good book on the Unix Philosophy, but it's worth noting that the ultimate expression of these ideas (Plan 9) was a failure, and the 'everything is a file' metaphor is arguably incorrect. I hope I didn't give the impression that it was not worth reading, especially in the sense that there are few other good sources for that information (even using Unix is not likely to teach you much about its whys and wherefores). I just think that it should be read in the proper context, and that recommendations should try to include that context.
I think this is a pretty distorted worldview. I'm confident most brick-layers would be happy to be taken for this kind of "complete ride by employers" in exchange for the cushy offices, offsite retreats, snacks, beer, endless perks, and $100k+ USD/yr salaries that software engineers tend to get in exchange.
Most developers I know get paid less than national average salary (for the uk) and are expected to deliver above and beyond, with non of the perks you mention (I didn't even get offered 2 weeks paternity pay in my previous job). Please don't get me wrong, I love what I do and I absolutely know how lucky I am to be here, but I just feel for the OP having a weight of expectation that isn't fair in any industry.
Assuming that the average dev receives "cushy offices, offsite retreats, snacks, beer, endless perks, and $100k+ USD/yr salaries" is a distorted worldview unto itself.
This seems like it could be quite interesting but unfortunately it's published on Medium, which is blocked in China. This being a Baidu project, is there a China-friendly version of the article?
Interestingly, the linked article isn't actually available inside of mainland China at the moment. Maybe they're not running their own blog through the China-enabled portion of their CDN?
I like the lending library / coffee shop notion as well, and if you don't have a lot of runway to try this, you might be able to put out a signup sheet asking people to pre-commit to a multi-month membership up front - if there's not enough interest there to keep you afloat (or get you close), try something else. Should serve to at least get baseline validation on the concept before you sink any real time / money / effort into it.
Unless I'm misreading the question, it's actually a good deal trickier than FizzBuzz - the difficult part isn't computing the "sustainability scores" from the input strings, but in maximizing the combination of product offers across the set of offers and customers. It's actually analogous to a rather well studied combinatorial optimization problem (that I won't call out by name here so as to avoid letting potential job applicants look up the answer too easily) that has a fairly non-obvious pseudo-polynomial time dynamic programming solution. The naive solution is exponential time (and still a bit tricky for a novice). I suspect the intent of the question is to find applicants that give the optimal solution rather than the naive one (and to weed out applicants that can't give any correct solution), but I could be mistaken.
Even after applying your patch I had a little trouble getting everything to link properly on x86_64 Fedora (14). I ended up manually tweaking my make files after running qmake.
Changed the LIBS line (in MLDemos/Makefile, _AlgorithmPlugins/<n>/Makefile.<n>, _IOPlugins/<n>/Makefile.<n>) to:
I think the issue we're all having stems from the structural redesign of opencv 2.2. Everything has been split up into smaller headers, and the functionality is similarly separated into different shared libraries. It's a more logical code structure, but it means that we need to have different makefile rules for pre-2.2 and 2.2+ code.
As far as -lhighgui -lcv -lcxcore is concerned, those libraries don't exist on my machine anymore. "highgui" is "/usr/lib/libopencv_highgui.so", and so on. That would explain why my 'fix' didn't work for you.
