Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
Could people please stop accusing people of being fake just because they write verbosly? That kind of behavior is part and parcel of the incredibly rude and mean-spirited behavior mentioned in that LinkedIn thing. Mike On Fri, May 17, 2024, 10:21 AM hiro <23h...@gmail.com> wrote: > or rename that linkedin garbage to "using AI to disincentivize open > discussion communities" > > On Fri, May 17, 2024 at 4:16 PM Jacob Moody wrote: > > > > > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/ > > > > This linked-in article is frankly disgusting, I suggest you take this > incorrect garbage down. > > > > > > On 5/17/24 07:43, Samuel Reader via 9fans wrote: > > > It is only a first draft, and it is not a finished product. I'll > correct the mistakes found. > > > > > > Thank you for the kind feedback. > > > > > > > > > > > > > > > Sent with Proton Mail secure email. > > > > > > On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> > wrote: > > >> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote: > > >> > > >>> an other interesting reading : > > >>> > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card > > >> > > >> > > >> I'm appalled and frankly furious about this article. It's blatant > > >> slander which can affect me in my professional career. I'm a phD > > >> candidate and my work is based on Plan 9 and developed on 9front; I > > >> was going to present it at iwp9 but could not once the venue was > > >> changed as it rendered it incompatible with my time table. > > >> > > >> The article lacks references to many of its claims, and the remaining > > >> ones directly contradict its points. The Register article is even > > >> linked incorrectly. A superficial reader would not bother to try to > > >> follow the links or find the article. For me this is clearly > > >> malicious attention-seeking. > > >> > > >> Regarding the pdf posted earlier[1], almost all of it is factually > > >> incorrect. As an example, there are no drivers for modern nvidia or > > >> amd chips or bluetooth. Many of the "system calls" listed in the pdf > > >> are not system calls (proccreate) or simply don't exit (vlongtime), > > >> and so on. In addition, it is trivial to recreate the same content > > >> with a query like the following: `Generate a detailed book-style > > >> document called "Revitalizing Plan 9: integrating modern enhacements > > >> into 9legacy" detailing all improvements introduced in 9front compared > > >> to 9legacy'. See for yourself in an excerpt below my email. > > >> > > >> I don't understand what the goal here is. All this post and pdf > > >> accomplish is spreading misinformation, promoting cancel culture, > > >> fostering community division and discouraging collaboration with > > >> 9front and even 9legacy, directly contradicting both Vic's claims and > > >> that of those who have sided with him in the thread. At this point, > > >> use of chatgpt in this thread is blatant and harmful. Please stop. > > >> > > >> Thanks, > > >> qwx > > >> > > >> [1] > https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf > > >> --- > > >> > > >> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy > > >> Introduction > > >> Plan 9 from Bell Labs has long been recognized for its innovative > approach to distributed computing. However, as hardware and software > technologies advanced, the need for a more modernized version of Plan 9 > became apparent. This need led to the development of 9front, a fork of Plan > 9 that incorporates numerous enhancements and updates, surpassing 9legacy > in several key areas. This document details these improvements, offering a > comprehensive comparison of the advancements introduced in 9front over > 9legacy. > > >> > > >> Chapter 1: Graphics and Video Drivers > > >> Improved Graphics Hardware Support > > >> One of the most significant areas of enhancement in 9front is its > support for modern graphics hardware. This includes: > > >> > > >> Support for Newer GPUs: 9front integrates drivers for the latest GPU > models, ensuring compatibility with modern graphics cards from > manufacturers like NVIDIA and AMD. > > >> Enhanced Frame Buffer Device: The frame buffer device driver has been > optimized for better performance, providing smoother graphics rendering and > faster display updates. > > >> Broad Chipset Compatibility: 9front supports a wider range of > graphics chipsets, allowing it to run on diverse hardware configurations > with improved stability and performance. > > >> Advanced Video Handling > > >> 9front has made considerable strides in handling video output, > particularly with high-resolution and multi-monitor setups. > > >> > > >> High-Resolution Display Support: Enhanced support for high-resolution > displays, including 4K monitors, ensures crisp an
Re: [9fans] PDCursesMod 4.2 released with upstream plan9 support
Nice! I've been wondering about textmode games on Plan 9. This should open up the whole world of Roguelikes, eventually. Mike On Sun, Oct 4, 2020 at 4:43 AM Jens Staal wrote: > > https://github.com/Bill-Gray/PDCursesMod/releases/tag/v4.2.0 > > PDCursesMod is a fork of PDCurses and we managed to bring fgb's old (3.0) > PDCurses port to the current PDCursesMod. > > Why would you need curses? > Lots of fun little curses-based things out there and PDCursesMod can build > many > things that are typically claimed to depend on ncurses (not stuff depending on > termcap though). > > Some examples: > > nbsdgames: > https://github.com/abakh/nbsdgames > > tetris: (replace "ncurses.h" with "curses.h") > https://github.com/brenns10/tetris > > I aim to port BSDgames and NetHack, but currently real life is taking all my > time. > > https://github.com/staalmannen/BSDGames > https://github.com/staalmannen/NetHack > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te27021add8ec4894-Me676f9083fb9e893fd1b753c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] troff book
Plain TeX (which is what KerTeX offers by default) doesn't seem that complex, but it does have the disadvantage of not offering much of a separation between format and content. Both LaTeX and some of the more sophisticated troff macro packages do a better job of allowing "structured" editing. Also, what level of font support is available in KerTeX and Plan 9 troff? I'm assuming that neither offers the level of "plug and play" support for modern Opentype fonts that can be found in XeTeX and Heirloom troff, but how are they otherwise? Mike
Re: [9fans] [RFC] fonts and unicode/utf [TeX]
On Thu, Jun 30, 2011 at 10:51 AM, Karljurgen Feuerherm wrote: > Thanks for this. Two notes: > >>Re-reading it, it's not "all ligatures" that are gone with > "Unicode-compliant fonts", but it spoke about the em- and en-dashes and > double quotes. So on these ones, I plead guilty. > > Alright. Not a big deal, it seems to me. Unless XeTeX has changed since I last used it, traditional TeX ligatures ARE still there.if you load the fonts properly. I always used tradition TeX punctuation pseudo-ligatures when I used XeTeX because, unlike accents which are easy to type and not used very frequently, dashes and quotation marks and frequently used and hard to type. Thus shortcuts are welcome. Mike
Re: [9fans] [RFC] fonts and unicode/utf [TeX]
On Mon, Jun 27, 2011 at 2:01 PM, wrote: > On Mon, Jun 27, 2011 at 01:34:07PM -0400, erik quanstrom wrote: >> >> i don't even have an opinion on this. i don't understand the conflation >> of the input character set and tex's internal representations. could >> you explain why you are taking about them as the same? >> >> to be brutally honest, tex could internally use an array of monkeys >> flinging poo to represent characters /internally/ and i would be much >> happer than with a reasonable internal representation and a difficult >> and incompatable external representation. at least that way the monkeys >> flinging poo are hermetically sealed within the program and not flinging >> poo all over my system. :-) > > In TeX there is, initially, a defined subset: ASCII. Because TeX is a > compiler/interpreter and one needs to be able to send some > "bootstrapping" commands. This can be rapidly overwritten (but starting > with some ASCII like characters). This can be almost arbitrary. > > What people were precisely arguing is precisely that external business, > and "state of the art" (that is soon to be "out of fashion") fonts and > whatever mood "du jour" should lead to the rewrite of TeX internals. > > I precisely claim to let TeX internals alone. The majority of the work > is external (the main being in the dvi drivers). If I want to use > ligatures, I shall be able to do. If others want to put directly the > code for the ligatured glyph, they can, but this is their problem and > not a holy rule. That's not how OpenType works, actually. It actually works more like TeX, in that it allows for files to store text as basic ASCII/Latin-1/8-bit UTF-8 subset format which an OpenType-enabled renderer (such as XeTeX, InDesign or even Office 2010) then presents (on screen or on page) as the correct ligature. Thus the big advantage of OpenType over, say Type 1, is that it offers a featureset much closer to Computer Modern's full set of ligatures, accents and alternatives than Type 1 ever could (at least without serious scripting to combine multiple Type 1 fonts containing all the needed glyphs into a single "virtual font" as described in your first post) > Unfortunately wrong. Read back the thread (if you really have > nothing more interesting to do). I have explained this "256 subfonts" > business in the first message, and immediately got answers that > the "correct way" was teaching TeX "modern" fonts. The subfont system works fine if you both have a complete Type 1 font set including all the "expert fonts" including the extra glyphs and the like AND are willing to put together a mapping for it. The problem is that fonts haven't shipped (to consumers, at least) in that form for about 10 years. Unless I fundamentally misunderstand the subfont system (which I admit that I might), for any font made within the last 10 years or so, using the subfont/virtual font system would entail the following steps: 1. Break the complete OpenType font down into a combination of PFBs and AFMs containing the complete set of characters between them, carefully remapping each glyph outside of 8-bit range into it so that they remain accessible. This may break the license agreement for many fonts and would almost certainly cause the loss of many kerning pairs, hints and other metadata (I'm not sure how much of that TeX uses, so that may not be as big a problem as it sounds) 2. Build the virtual font mappings as with a with a "real" Type 1 set 3. Hope for the best. Given the complexity of the process involved, I would hope you can understand why, as a USER, teaching TeX to play nice with modern fonts looks like a good way to go ;) Again, none of this is meant as a put-down of your quite impressive work, but rather as a reminder of some areas where others might run into problems with making USE of said work. Mike
Re: [9fans] [RFC] fonts and unicode/utf [TeX]
On Sun, Jun 26, 2011 at 3:57 AM, wrote: > I don't know what "automagic" ligatures are; but ligatures are here in > the kerTeX fonts, user having nothing special to do to have them. Small > caps are here. Using the system fonts is here too, at least for T1 > fonts: afm2tfm(1) makes them available. For other fonts format, > writing a whatever2tfm(1) will do the job. In general using a simple Type 1 font isn't going to get you things like true small caps, ligatures (beyond maybe the basic "fi" and "fl") or the ability to choose between old-style and lining figures. The 256 glyph limit means that you had to split things up into multiple fonts, This works well enough for simply creating a PostScript file that will be fed straight to a laser printer, but for creating searchable PDF files, it's far from ideal. In TeX, it also require a lot of manual work above and beyond what would be needed to get those features using Computer Modern. With OpenType support (and using OpenType fonts, of course), typographic features become as easy to use with third-party fonts as they are with Computer Modern. > And "archaic" is definitively a marketing sentence, not a scientific > judgement: "Euclid? Well... it was perhaps good for the epoch..." True enough. it's more my opinion than anything else. Still, it must be an opinion shared by someone else, given the widespread use of "fontspec" wherever available compared to the older methods. >> The problem is that these modern implementations are HUGE. On the >> average Linux system, TeX, LaTeX and other paraphernalia seem to take >> up well over 1 GB these days. I've given up on TeX because it's just >> so darn big. > > So have I. > kerTeX is 1/100th of the current TeX distributions and is C89, that is > the most portable. It lacks some Heirloom troff features, but it is for > text and mathematics, includes a font designer: METAFONT, a figure > designer: MetaPost and a bunch of debugging utilities, coding utilities > (WEB), fonts and a state of the art documentation. I'm not disparaging your work. In fact I think its pretty good. I was mainly trying to point out the problems that have arisen in some "modern" TeX distros in the past. > So I stick to kerTeX. And I have recorded what _you_ propose to do ;) > Since you seem to claim that the way _you are engaged in_ is easier than > the road I have taken, you should have finished before I have finished > kerTeX, rendering it /* sigh */ obsolete... I doubt that, as tounge-in-cheek suggestions seldom seem to turn into working ideas (at least when they come from me)
Re: [9fans] [RFC] fonts and unicode/utf [TeX]
Modern TeX implementations like XeTeX and LuaTeX handle UTF-8 natively and also bring all sorts of benefits like OpenType support (automagic ligatures, real small caps, selectable lining or old-style figures and more) and the ability to define fonts from the system font pool rather than using archaic incantations and magic scrolls from the early 90s. The problem is that these modern implementations are HUGE. On the average Linux system, TeX, LaTeX and other paraphernalia seem to take up well over 1 GB these days. I've given up on TeX because it's just so darn big. There is, however, hope. Heirloom troff manages to include many of the same whizz-bang typographic features as XeTeX and friends (including Unicode support, smartfont support, easy loading of fonts in modern formats) while taking up about 1/100th the resource footprint. Clearly what we REALLY need is a filter that takes LaTeX sources and processes them into TROFF commands to feed to a port of Heirloom troff ;) Mike
[9fans] Getting Networking Going on QEMU?
Hello, fellow 9fans. I'm a Plan 9 newcomer and I've been playing with getting a simple standalone Plan 9 system going in QEMU and I'm having problems getting the networking to work. I tried running "ip/ipconfig" and "ndb/dns -r" which should be sufficient to get the networking going using the built-in NAT and DHCP stuff in QEMU but it doesn't seem to work. Attempts to run a simple DNS query fail miserably like so: > google.com ip !dns: dns failure Am I missing something? Do I need to edit some configurations somewhere? I'd really like to get my little Plan 9 system online so that I can connect to some of the various resources available (contrib, source pulls, etc) and I'd appreciate any help you folks can give. PS: Yes, I know that 9grid has perbuilt images that "just work". I was hoping to learn how to get things going myself so that I learn a bit more than I would using a turnkey system. Mike
Re: [9fans] troff macros for typesetting books/longer texts
On Fri, Mar 25, 2011 at 11:32 AM, John Floren wrote: > Well, I think it's more that Richard Stallman was so ridiculously in > love with ITS's documentation system (which was pretty good for its > time, I admit) that he decided to clone it for Unix. > > Could the bloat of GNU tools merely be a ploy by rms to force people > into using info? :) To be fair, Unix tools were getting bloated even without GNU (cat -v, anyone?). GNU just introduced the --verbose-lispmachine-style-option-syntax to the mess. Frankly, I think that's the problem with a lot of GNU stuff: it was made by RMS and other folks who mainly came out of the PDP-10 and LISP Machine tradition which doesn't really mesh well with the Unix tradition. Programs with lots of options were IMPORTANT when your shell environment was really just a hacked up version of a debugger from the mid-60s because you didn't have things like pipes to make programs play nice together. On the other end, having a verbose syntax didn't really matter when you were working with a smart LISP system or TWENEX or some other system with really good completion support. Thus the problems with GNU can be directly traced to the fact that it was written by people with brains scrambled by DDT on the one hand and spoiled by TWENEX and standalone LISP on the other. Mike
