Re: uhidev(4), ukbd(4) changes

[Michael]

Hello,

On Mon, 14 Aug 2017 05:49:28 -0500
"Jonathan A. Kollasch"  wrote:

> There's a (probably remote) chance my changes to uhidev(4) and ukbd(4)
> might have broken things.
> 
> Particularly, I was not able to test that ukbd(4)'s
> "FLAG_APPLE_FIX_ISO", "FLAG_APPLE_FN", "FLAG_GDIUM_FN" still function
> correctly.

As far as I can tell from just poking around  little, FLAG_GDIUN_FN
still works as intended.

have fun
Michael

Re: Fixing swap1_stop

[Christos Zoulas]

On Aug 15,  9:33pm, idler...@fastmail.fm ("Ian D. Leroux") wrote:
-- Subject: Re: Fixing swap1_stop

| On Tue, 15 Aug 2017 02:11:37 -0400 chris...@zoulas.com (Christos
| Zoulas) wrote:
| 
| > On Aug 14, 10:50am, idler...@fastmail.fm ("Ian D. Leroux") wrote:
| > -- Subject: Re: Fixing swap1_stop
| > 
| > | Any preferences for a conveniently-parseable format?  My first
| > | instinct is to simply drop the spacer words ("on", "type"),
| > | systematically shquote() the device and mount-point and
| > | space-separate the flags.  That would look like:
| > | 
| > | '/dev/wd0a' '/' ffs synchronous local
| > | 'tmpfs' '/var/shm' tmpfs nosuid local
| > 
| > The flags can be complicated (see source code)
| > 
| > | That's directly parseable in shell (first three fields are device,
| > | mount point and fstype, any leftovers are individual flags) and
| > | doesn't require the design of another date-style formatting
| > | language.  Are there other, better ideas?
| > 
| > We can specify a format with % escapes for each field...
| 
| I was hoping to avoid being guilty of yet another printf-style
| mini-language.  But I don't currently have any better ideas, so let's
| work this one out.  The filesystem, mount point and device get an
| escape each (say %f, %m and %d respectively).  How should the flags be
| handled?  One escape for the whole comma-separate flag string (as in
| the current output)?  That's easy to implement and manageable to work
| with, since the flag names are well-behaved single words that are not
| under user control, so they could be parsed with shell globs, something
| like:
| 
| FLAGS=$(mount -F '%F')
| case $FLAGS in
| *local*) # do local filesystem stuff 
|   ;;
| *nosuid*)
|   ;;
| esac
| 
| Alternatively, each flag could get its own % escape (perhaps one that
| expands to "yes" or "no"), but that makes it harder to write a format
| string that reproduces the default output.
| 
| I don't currently have a use for extracting the flag information (since
| my immediate interest is just in getting a reliable mount point name),
| so I'm not sure which format is most useful in practice.

Lets put all the flags together as a comma separated list?

christos

Re: Fixing swap1_stop

[Ian D. Leroux]

On Tue, 15 Aug 2017 16:20:41 +0700 Robert Elz  wrote:
>   | Any preferences for a conveniently-parseable format?
> 
> I'd prefer to omit sh commands that will cause the mount to be
> performed, so that the filesystem returns to its current state.

What's the use-case for this?  If I want the filesystem to be mounted
in its current state, I do nothing.

>   | That would look like:
>   | 
>   | '/dev/wd0a' '/' ffs synchronous local
>   | 'tmpfs' '/var/shm' tmpfs nosuid local
>   | 
>   | That's directly parseable in shell
> 
> How?   What sh code would you use to read that and make it useful,

My mistake.  I thought that "read" follows the usual shell quoting
rules.  It doesn't, so this won't work as well as I'd hoped.

> and don't forget the case where the device or mount point contains a
> ' or a newline char.

I hadn't (in the sense that shquote(3) deals with both of these cases),
but I (and shquote(3)) assume the usual shell quoting rules (where single quotes
can protect newlines), which won't work with read.

> I'd prefer
> 
>   mount -t ffs -o synch,local $'/dev/wd0a' $'/'
> 
> (where the quoting can be omitted when, as here, it is not needed),
> but this would require $'' support in sh first (we want that rather
> than just '' quoting so weird chars, like newlines and single quotes,
> can be included without making life difficult).

I've never seen $', what is its intended meaning?

> Then if you want to perform the mount, you just run that line as a sh
> script.
>
> On the other hand, if you want to find what is mounted where, you
> first just define
> 
>   mount()
>   {
>   shift $(($# - 2 ))
>   DEVICE="$1"
>   MOUNTPOINT="$2"
>   }

This feels backwards to me.  It seems to be optimized for making it
easy to run a mount command that does nothing, whereas actually
extracting information about the existing mounts (which, to my mind, is
the main use-case for this feature) now requires you to redefine a
basic command and do a dance.  The dance is, incidentally, a bit more
complicated than you show since we still need to be able to run
"mount -p" in order to generate the output which will then be executed
using your new, different, meaning for "mount".  Both meanings must be
simultaneously in scope (which you can probably do by always giving the
full path /sbin/mount when you mean the binary and the bare command
name when you mean the shell function, but that clashes with the
typical styles of the rc.d scripts).

Could you explain why you prefer this output format?  What problem do
you hope that it solves?  As a solution to my problem
(stopping /etc/rc.d/swap1 from unmounting essential filesystems), it
smells over-complicated to me.

-- IDL

Re: NetBSD with a gaming keyboard

[Swift Griggs]

On Tue, 15 Aug 2017, Christian Baer wrote:
I haven't actually seen the new one. It has tempted me for a while now, 
but all too often, remakes of movies I knew as a child, have not been 
too good. Just think of Star Wars Ep1. So, I was actually quoting the 
1982 movie.


There is no equal to Jar Jar Binks in the new Tron. However, I have very 
little nostalgia about the old one. So, YMMV, but I thought the new one 
was even better. Flynn's Arcade was awesome, especially the scene with the 
psuedo-Unix machine he "enters" the grid via.


This is actually the part that I am a little nervous about. If a drive 
breaks and I have to replace it, will the rebuild work correctly?


Yes. I can vouch for that. However, once I have basic operations like bad 
disc replacement taken care of, I don't spend much time worrying about the 
block level for resiliency. I worry about file level *backups*. Then it 
doesn't matter what you use for a backing store unless it's too slow or 
too unstable.


Because I have not actually followed the development of ZFS on different 
platforms, you lost me a bit.


To the point then, Oracle thinks *they* are the single-source-of-truth 
about ZFS. Their versioning scheme reflects that.


I remember reading a while back that FreeBSD is or could be the de facto 
reference (development) platform for ZFS and not Solaris.


Well it could be a reference platform, depending on who you ask, as long 
as you don't ask Oracle. The version of ZFS that comes with Solaris 11 is 
so different it simply won't work with anyone else's anymore, including 
freeware Solaris distributions.


Since I had no plans to use Solaris (which really sucked rocks 
concerning hardware support on amd64 the last time I checked)


I haven't had problems with AMD64 hardware with Solaris x86_64, but I've 
got massive problems with recommending it due to SMF being an unvarnished 
turd pool in my opinion (along with 100% of the other places where they 
implemented XML and binary-opaque SQLite databases which replaced static 
text files). Most of the actual Solaris 11 bugs I've seen have been with 
networking code and dladm. I work in a support role for legacy and current 
Unix systems. 90% of the calls I get on Solaris now are for changing basic 
IP setups since it's become such an unreliable PITA mere mortals can't 
figure out how to make it work consistently, even after doing everything 
Oracle's documentation says and it still won't work. Several have 
downgraded back to Solaris 10 or permanently delayed upgrading from 
Solaris 8 or 10 after experiences with 11. We shouldn't be too surprised. 
In my personal opinion, SunOS/Solaris has been going downhill ever since 
the move to SysV with a brief pause at SunOS 5.6 and 5.8.


I don't know. I always imagined that because FreeBSD hat great working 
disc encryption via the GEOM subsystem (i.e. geli and gbde) - and both 
work well with ZFS - there was little motivation to include and maintain 
another encryption system.


Except for the fact that ZFS is it's own volume management system and can 
compete with GEOM as well as cooperating with it. So, it's conceivable 
that someone might want encryption without the hassle or complication of 
GEOM and staying with "native" ZFS zpool block devices. There is 
chattering in FreeBSD land on just that topic, and the natives don't seem 
satisfied with GELI. See this thread:


https://forums.freebsd.org/threads/56869/

There are distinct and specific advantages of having encryption in the 
ZFS/zpool toolbox due to the architecture of the L2ARC and ZIL. So, it's 
not even a wrongheaded thing to want.


Basically, I have to ask: What is the current status/version of ZFS on 
Solaris, NetBSD and FreeBSD? Linux is a special case due to the "unique" 
and annoying license.


My assertion would be the current state of ZFS for all of them is 
"Fragmented and dynamic". I will point out with a certain level of 
schadenfreude that Linux seems to be the *least* well integrated and 
functional of the lot. They can thank the GPL for that.



I don't quite see the parallels here.


Okay forget the stupid analogy. I'll be blunt. I find the expectation by 
Oracle that folks will bow to *their* special snowflake version of ZFS 
annoying. We aren't all going to buy an Oracle service contract for 
Solaris 11 due to the overwhelming greatness of the judgment of the ZFS 
coders at Oracle. We don't owe them anything except maybe pat on the head 
for the original ZFS effort which was basically done by a mostly different 
group of people in a different company that no longer exists. I don't feel 
any technical debt to Oracle. They are just owners of some aging IP.


Honestly, they seem to be more interested in BTRFS than in ZFS sometimes.

If the kind of music (or whatever) you make is exactly what the people 
want, good for you!


... and my point is if you make a garbage album to appease your "artistic 
vision", don't go on talk shows crying about how your fans 

Re: NetBSD with a gaming keyboard

[Christian Baer]

---=== Warning ===---

This post hast TL;DR potential! :-)

On Thu, 10 Aug 2017 12:13:48 -0600 (MDT)
Swift Griggs  wrote:

>> Greetings, Programs! ;-)  
> If you haven't seen the new Tron Legacy, I'd recommend it. It's
> awesome. I'm not sure which one you are quoting :-)

I haven't actually seen the new one. It has tempted me for a while now,
but all too often, remakes of movies I knew as a child, have not been
too good. Just think of Star Wars Ep1. So, I was actually quoting the
1982 movie.

For those who have no idea what we are talking about... :-)
http://www.imdb.com/title/tt0084827/

> You could just reverse the order, and put the CGD devices on top of 
> RAIDframe instead of visa versa. As far as I imagine, it's not
> important as long as it's encrypted by the time you go to lay down a
> file system.

This is actually the part that I am a little nervous about. If a drive
breaks and I have to replace it, will the rebuild work correctly? In
theory, it will, but there is quite often a difference between theory
and practice. But this is something we can discuss should the need
arise in the future.

> 
> Also, just as an aside, you don't have to do any of this in recent 
> versions of Solaris since they've held back the encryption
> functionality in ZFS. Oracle has been pretty narrow minded about new
> ZFS features. They want to camp on them, highlight them as "value
> add" that comes with Solaris versus a negative poo-pooing of FreeBSD,
> Illumos (or whatever these free Solaris distros call themselves now -
> I can't keep up with that crap), and ZFS-on-Linux implementations.
> 

Because I have not actually followed the development of ZFS on
different platforms, you lost me a bit. I remember reading a while back
that FreeBSD is or could be the de facto reference (development)
platform for ZFS and not Solaris. Since I had no plans to use Solaris
(which really sucked rocks concerning hardware support on amd64 the
last time I checked), I didn't concern myself too much with the
versions of ZFS on anything else than FreeBSD. Why the encryption of
ZFS has never made it to FreeBSD, I don't know. I always imagined that
because FreeBSD hat great working disc encryption via the GEOM
subsystem (i.e. geli and gbde) - and both work well with ZFS - there was
little motivation to include and maintain another encryption system.

Basically, I have to ask: What is the current status/version of ZFS on
Solaris, NetBSD and FreeBSD? Linux is a special case due to the
"unique" and annoying license.

> 
> It reminds of a band that made a really great album, that album gets
> them lots of new fans and then the artist makes another album that's
> sucks but just expects the new fans to buy it automatically. Then
> they go on talk shows and whine about how their artistic vision has
> changed and the old fans are just holding them back (but should pony
> up $$$ whenever asked). Screw that. Life is hard, sometimes you gotta
> cater to your fans and drown your stupid new "artistic vision" in the
> bathtub. In my personal opinion, Oracle's vision for Solaris has
> pretty well sucked, including their "leadership role" for ZFS. The
> future of ZFS doesn't seem all that certain to me (FreeBSD is
> providing more leadership than Oracle).
> 

Are these by chance women? :-D

I don't quite see the parallels here. :-/ If you make something (music
or anything else), then you can either try to make something you like
(and risk not so many other people liking it) or you can try to please
the masses and boost your sales. If the kind of music (or whatever)
you make is exactly what the people want, good for you! You will be
rich. But there is no entitlement for that. People are free to buy
what they want and if they think your newest album sucks, you might
have to drive your old car for a little longer.

I don't quite get what this has to do with ZFS on Solaris or anything
else - especially because Solaris is not exactly Oracle's main cash
cow.
 
> It is a mess. A structured, deterministic, reliable mess, but still a
> mess when compared to ZFS. The idea, I think, was to follow a more
> Unixy philosophy and split up block-level and file system
> functionality. It turns out that's a good idea because if your volume
> management still rocks but a better file system comes along, you are
> able to take advantage of that. If some filesystem comes along that
> kicks ZFS's butt, you have to throw out the ZFS volume management
> baby (zpools) with the file system bathwater.

Not really. Even is something else comes out, that is better than ZFS
(HAMMER2 isn't looking too bad right now), then changing the file
system probably won't be worth the effort unless my requirements change
quite a bit (which I currently don't see happening), or the
opportunity arises (because for instance, I have to change the
hardware). But as long as ZFS works, I probably won't have any pain
that compels me to make any changes.
 
> I use generic ones at least 

Re: Fixing swap1_stop

[Robert Elz]

Date:Mon, 14 Aug 2017 10:50:01 -0400
From:"Ian D. Leroux" 
Message-ID:  
<1502722201.165795.1072902592.394c1...@webmail.messagingengine.com>

  | > I am not sure if it is a good idea to change the output in the default
  | > case. Perhaps we should add a flag to make the behavior explicit.

A common flag used in several other places for this is -p (portable output).

  | > But
  | > at that point (if we add a flag), we might as well make the new output
  | > convenient to parse.

Yes.

  | Any preferences for a conveniently-parseable format?

I'd prefer to omit sh commands that will cause the mount to be performed,
so that the filesystem returns to its current state.

  | That would look like:
  | 
  | '/dev/wd0a' '/' ffs synchronous local
  | 'tmpfs' '/var/shm' tmpfs nosuid local
  | 
  | That's directly parseable in shell

How?   What sh code would you use to read that and make it useful, and
don't forget the case where the device or mount point contains a ' or
a newline char.

I'd prefer

mount -t ffs -o synch,local $'/dev/wd0a' $'/'

(where the quoting can be omitted when, as here, it is not needed), but
this would require $'' support in sh first (we want that rather than just
'' quoting so weird chars, like newlines and single quotes, can be included
without making life difficult).

If that is seen is useful, I can bump $'' support up the priority list
(aside from its effects on $LINENO in some weird cases, implementing it
is trivial, as FreeBSD have it already...)

Then if you want to perform the mount, you just run that line as a sh script.

On the other hand, if you want to find what is mounted where, you first just
define

mount()
{
shift $(($# - 2 ))
DEVICE="$1"
MOUNTPOINT="$2"
}

and then run the command, which will (if I did the arithmetic correctly,
this is untested) result in setting DEVICE and MOUNTPOINT to the relevant
strings).  If you want other info as well, that function can just ba made
more complex.

(then you can unset -f mount if you need to later do real mount commands).

kre