Re: Fonts for console/fb for various locales: a proposal
On Mon, Sep 30, 2019 at 11:01:51AM +0200, tlaro...@polynum.com wrote: > On Mon, Sep 30, 2019 at 10:32:40AM +0200, Martin Husemann wrote: > > I guess noone would object a metafont2wsfont converter tool. > > Look at the true type tool Michael mentioned in xsrc/local and do something > > similar for metafont. > > I have already planed to re-start with the Hershey fonts, for reasons > explained in my initial mail and for others and this will be combined > with TeX (kerTeX). So there will probably be something in this > line, at the end, even if it is only for my own use. Sorry for late comment but I would like to suggest mlterm-fb as - probably - easiest solution for Your case (if I understood problem correctly, of course). mlterm running in framebuffer console is capable to use wide range of standard X fonts[1] without hassle. If You want to convert fonts to wsfont You may take a look at some additional resources. In addition to already mentioned there is also my small tool[2], created for my own work for bitmap terminus fonts (see [3] for gallery) - it isn't useful for converting vectors, but may provide a hints about your own methods of mapping from UTF codes or Adobe names to particular code pages (wide range of definitions is provided by original terminus package, for my case I made only one, for cp437). 1 - https://www.mail-archive.com/netbsd-users@netbsd.org/msg10136.html 2 - https://github.com/aniou/bdf2wsfont 3 - http://smutek.pl/netbsd/wsfont/terminus/ 4 - http://terminus-font.sourceforge.net/ -- Piotr 'aniou' Meyer
Re: Removing PF
On Sat, Mar 30, 2019 at 10:55:23PM +0100, Michael van Elst wrote: > Have you actually looked at these commits? He changed parts of the > internal network API and had to adjust PF code to match these changes > and keep compiling. You could call that 'maintenance' but hardly 'fixed > real bugs'. Yes, I did. :) http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dist/pf/net/pf.c?rev=1.78&content-type=text/x-cvsweb-markup&only_with_tag=MAIN Regards, -- Piotr 'aniou' Meyer
Re: Removing PF
On Sat, Mar 30, 2019 at 08:26:23PM +0100, Michael van Elst wrote: > On Sat, Mar 30, 2019 at 08:10:21PM +0100, Maxime Villard wrote: > > > ... sure, meanwhile you didn't really answer to the core of the issue, which > > I think was stated clearly by Sevan ... > > The issue is that we need to work on npf before we can drop other code. > > If you care about bugs in pf, open PRs, best with reproducable test > cases, or just fix the bugs. There are bugreports already, one with statement related to this thread (from #50809[1], Feb 2016, three yars ago): : We really need to decide what to do with pf and ipf. People keep using : them but it seems that the versions in the tree have bit rotted and we : get kernel bugs that nobody seems to care about fixing. Particularly : in the pf case, the code is really old and should be really updated to : the latest pf if we want to maintain this packet filter in the tree. Although there was conclusions that "NPF is the seemly lack of BRIDGE_IPF" I found that Mindaugas wrote that it should work[2]. BTW: IMO Maxime's arguments are strengthen by fact that he ALREADY fixed real bugs in PF, as commit history in [3] shows. 1 - https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50809 2 - https://mail-index.netbsd.org/tech-net/2017/03/23/msg006289.html 3 - http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dist/pf/net/?only_with_tag=MAIN Regards, -- Piotr 'aniou' Meyer
Re: Removing PF
On Sat, Mar 30, 2019 at 12:59:00PM -, Michael van Elst wrote: > >Just to get the facts straight: NPF has a bigger market share *outside* > >NetBSD, at least certainly for commercial users. They also contribute. > > Ironically, the same is also true for PF... But contributions to PF are made against OpenBSD kernel, true? And the essence of problem is that: - NetBSD version of PF is too old to adapt them without ton of work, - even current PF in OpenBSD doesn't fit very well into MP kernels and that makes "fresh" import cumbersome and fruitless I'm right? Regards, -- Piotr 'aniou' Meyer
Re: Removing PF
On Sat, Mar 30, 2019 at 01:21:27PM +0100, Johnny Billquist wrote: > Are you saying that NPF is not being updated or supported? > Should we maybe remove it? > Having broken code around for 8 years without anyone even much noticing > (except you maybe) or fixing it would suggest the code is rather rotten, and > little used. > > Only half a :-) intended. Do you think that there is any equality between remote-triggered crash and lack of specific feature? BTW: you joke makes strong argument against PF - there wasn't push for updating NPF features because they already works in - as we NOW know - buggy and insecure PF. PS. Looks like Open, with larger userbase hasn't similar objections before pruning cumbersome code. -- Piotr 'aniou' Meyer
Re: kernel frameworks for jumbo frame
On Sun, Mar 10, 2019 at 08:33:43PM +0100, Gert Doering wrote: [...] > On a system that only has one ethernet card, it's highly annoying > that I have to figure out if this is a "em0" or "igb0" - or an > "eno1" vs. "enp0s25" (both "onboard ethernet 0", but BIOS tables > leading udev to believing the second one isn't). So "eth0, always" > would be very convenient. Or possibly "eth0" for "wired ethernet" > and "wifi0" for wireless - as that's a common scenario. Nowadays I'm pretty sure that so-called "predictable interface names", dependent on physical layout of mainboard was a terrible mistake. Hardware itself doesn't guarantee consistent and dependable behaviour, especially between different vendors. Some examples: onboard ethernet card on my mainboard was identified as enp0s25 but inserting SERIAL controller (four RS232 ports) into PCIe slot lead to renaming onboard interface to... enp16s0. Why? I have no clue. Friend of mine has two-ports Intel card. Internally implemented as two different PCIe functions and available as... enp0s0f0 and enp0s0f1d1 (but it is subject to change between different kernel versions 8-0). With a brand-new mobo there is no chance to guess interface name without test run. Classic Linux behaviour has two possibilities: simply "eth0" in any case or interface renaming based on MAC-addresses (fortunately MAC addr is usually known). BSD names also gives us a chance - usually we know something about network card manufacturer. -- Piotr 'aniou' Meyer
Re: noatime mounts inhibiting atime updates via utime()
On Tue, Dec 04, 2018 at 08:23:20PM -0800, Jason Thorpe wrote: [...] > Honestly, I think atime is one of the dumbest thing ever. But if one > must support it, then I think the following is a reasonable > compromise: > > -- If one is asked explicitly to set the atime by the user, then by > all means, go for it. > > -- Implicit atime updates made by the file system should NEVER trigger > an I/O, but merely update the in-memory copy of the inode. If, for > some reason, that inode is pushed out to disk for some other reason, > then by all means allow the atime field to be updated at the same > time. It looks like a behaviour similar to "lazytime", recently introduced in Linux, after some years of experiments like "relatime". A short list of currently known behaviours (in different OS-es): https://en.wikipedia.org/wiki/Stat_(system_call)#Criticism_of_atime Regards, -- Piotr 'aniou' Meyer
Re: amd64: svs
On Sun, Jan 07, 2018 at 12:26:00PM +0900, cl...@csel.org wrote: [..] > The Redhat and Microsoft implicitly says "Intel will release microcode > soon". I hoped to it. > > the Linux supported by the google goes to the KPTI, maybe, > it means the Intel does not plan to mitigate by the new microcode. According to [1] Intel had known about issue for months: Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01 [1]. Lack of already available microcode updates, lack of release dates for particular cores and that all PR (mis)statements from Intel makes me doubt about Intel's will and ability to control situation. Few days ago even hardware manufacturers, like Cisco[2] wasn't sure about impact of bug (so - no early disclosure from Intel at all, even for them?). Today Cisco released additional informations - but take a look at "fix release date" for UCS Servers[2]! 1 - https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html 2 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel -- Piotr 'aniou' Meyer
Re: meltdown
On Fri, Jan 05, 2018 at 02:48:11AM -0600, Dave Huang wrote: > On Jan 4, 2018, at 15:22, Phil Nelson wrote: > > How about turning on the workaround for any process that ignores > > or catches SEGV.Any process that is terminated by a SEGV should > > be safe, shouldn't it? > > Isn't there a suggested mitigation? Seems to me NetBSD should implement > it as suggested, rather than coming up with its own special criteria > for when to enable the workaround. BTW: latest summary below: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html https://www.theregister.co.uk/2018/01/05/spectre_flaws_explained/ Regards, -- Piotr 'aniou' Meyer
