Probably the temporary solution to obtain the Estonian uppercase Š and Ž [S and Z with caron (ˇ)] without Shift + AltGr, I note in https://code.9front.org/hg/plan9front/rev/5b6853beadb4 you've written a Shift + AltGr (table 7) for Polish, would be using the caron (ˇ) mapped to key 41 followed by Shift s or Shift z; it was a mistake to earlier map a mode 4 in my fix of /sys/lib/kbmap/ee. It is a bit of an inconvenience to have an AltGr mapping to š and ž, but not a Shift + AltGr mapping to Š and Ž, but that's the best I can do for now. I send a new ee file without the mode 4.
https://code.9front.org/hg/plan9front/rev/851d5d9022af
these should not be in here
1.97+4 31 'Š
1.98+4 44 'Ž
https://code.9front.org/hg/plan9front/rev/378ba39fc90a
Sincerely,
Eric Lindblad
The /sys/lib/kbmap/ee file seemed to have CRs in it. If a first column in the table
(for modifier key) as 4 is for Alt Gr + Shift then the attached (UTF-8 without BOM)
should work as a replacement ee file.
Best Regards,
Eric Lindblad
the openssl we currently use is outdated and will be removed
soon. webfs will handle the https for us with native tls code.
keys have to be stored in factotum for everyone who also wants
to commit directly.
this is a reimplementation of cpu and import utilities in rc using a tlsclient
and tlssrv as the encryption and authentication layers. there is only one new
service, which after authentication and encryption setup accepts an arbitrary
rc script over the network and executes it with the standard filedescriptors
redirected to the conversaion (this is *after* authentication and in the
context of the authorized user).
the new rcpu program has a few improvements over cpu(1):
- doesnt mangle program arguments
- the remote process will get the clients standard file descriptors, so error
and output are separated and you can consume the clients input from the
remote side :-)
- forwards error status of remote process
theres no backwards mode for rimport, but a new program called rexport
for the same purpose.
all these services use exportfs without the bolted on initial handshake,
so the hope is to clean up exportfs in the future and remove all the ugly
crap in there.
this generates a disk image (to be written to usb or
sdmmc card) containing 9fat partition with kernel and
a hjfs filesystem partition with the 9front distribution.
this could be easily extended to generate raspberry pi
images as well, but i have no hardware to test.
rebuilding the xref table does not work for pdfs with
compressed object streams. as a work arround, we skip
xref table verification and ignore wrong xref gen #
for gen 0 objects.
