Feedback please: foundation of a laptop and desktop work group

[Deleted member 81054]

Yes, I'm old enough guy that need to purchase Accelerated X for usable (acceptable speed) X11 environment on 486DX4-100 class or Pentium 66 class with ISA or VLB based Graphics accelerator, if I recall correctly.

FreeBSD (or maybe it was NetBSD) used to run on a 386SX with 4 MEGAbytes of RAM. Was there some step that wasn't needed, back then, that IS essential, now, to setting up a system?

(sigh) And folks lament Microsoft's "bloat"...

 

[Deleted member 81054]

And back to GUI installers, I want to recommend people developing it to focus on "installer for creating 100%-configured-for-target-cards" on mighty amd64 DEs, preferrably with emulators to test before setting the created media into actual boards. It would be quite helpful for them

I don't think you have to abandon an 80x24/25 line text display. You just have to come up with alternative ways to get more EFFECTIVE display real estate. No need for color; let termcap define the display attributes available (and treat them as redundant -- e.g., the window title is only displayed in BOLD to emphasize it, not to differentiate it from other text on the screen!)

Display the scripts actions on another VTY (with a PERSISTENT note on the main installer screen telling them how to get to that VTY -- and, a note THERE explaining how to get BACK!)

I have often designed devices ("appliances") with nothing more than a standard serial port as the primary I/O for user interaction. I use a small windowing and menuing package I wrote atop curses to allow the user to see what he needs to see in any given part of the interface. E.g., displaying a clock is trivial (create a small window off to the side and periodically paint the current time into the virtual screen buffer and let curses repaint the screen, as appropriate)

But, you have to plan ahead so you don't just wander into a situation where you've consumed too much of the screen to allow the user to gain access to things that he might want/need to see.

 

[T-Aoki]

FreeBSD (or maybe it was NetBSD) used to run on a 386SX with 4 MEGAbytes of RAM. Was there some step that wasn't needed, back then, that IS essential, now, to setting up a system?

(sigh) And folks lament Microsoft's "bloat"...

Just I wanted to try X11. Dumb framebuffers were too slow, CUIs or X11 with Accelerated X was mostly OK. Why I've not chosen FreeBSD as my daily driver at the moment (2.1.6[.1] at the first try) was that Japanese input methods was not enough for me (so CUI was not an option).

 

[T-Aoki]

Display the scripts actions on another VTY (with a PERSISTENT note on the main installer screen telling them how to get to that VTY -- and, a note THERE explaining how to get BACK!)

And preferrably, split stdout and stderr into different vty would help noticing whether any errors happened or not.
Error messages are otten losts within regular outputs, scrolled out.

What's essential would NOT be whether its GUI or not, but can be used straightforward or not. For example, as I've noted in another post, disallowing selection of problematic (conflicting, illegal in chosen specific countries via timezone setting, and so on). And clarifying what are actually mandatory and what are optional (can be ignored), and what are illegal.

For example, not all countries allows all defined WiFi bands. For this kind of cases, choosing correct regdomain automatically by timezone configuration should be strongly wanted.

Another thing I've encountered was that the installer wanted to configure domain name (at the moment, sysinstall) and, if I recall correctly, could not proceeding without it. If it was allowed to be blank to proceed (with notes that stating optional item for domain holders only), or defaulting local domain (at the moment, none, but .local was widely introduced as OK) would be OK, too. Recently, .internal seems to be proposed for non-exposing TLD.

 

[Deleted member 81054]

And preferrably, split stdout and stderr into different vty would help noticing whether any errors happened or not.
Error messages are otten losts within regular outputs, scrolled out.

This is a tough one. I tend to route stdout and stderr to different files during a kernel build, but, I can rcognize the files throwing the complaints without needing to see the message intermixed with stdout.

[If ALL (!!!!!) messages clearly began with ERROR or WARNING -- clearly not the case for the tools invoked by the installer (unless the installer traps the errors and issues its own messages -- then its relatively easy to search for them in a stream.]

Splitting them out makes it easy to see IF you have errors and what they "claim". But, because the preceding command line is not present, you may end up scratching your head to sort out what THREW the error.

I like an installer that lays out the steps in a sequential "menu", letting me jumpt to any that I might want to address, NOW. In a monochromatic presentation, steps that need to be completed (or, that HAVE been completed) can be indicated with BOLD, UNDERLINE, etc.

This, unfortunately, complicates the installer and forces it to be designed with dependencies baked in; e.g., changing the partition layout obviously would (could??) invalidate any tarballs that have already been unpacked (though one could design logic to make those checks).

Going back to change the root password should be possible at any point. Ditto setting time, date, timezone, hostname, domainname, etc. You (the designer) just have to ask yourself what the ACTUAL dependencies are, and not rely on how YOU would perform the install.

[It's always annoying when <something> wants my name, address, etc. before letting me get to the body of the form. E.g., why do you need that information to let me estimate what my tax liability will be? Isn't that only dependant on my income (dependants, filing status, etc.)?]

What's essential would NOT be whether its GUI or not, but can be used straightforward or not.

"You" also have to decide if you want to address all installation needs, user types, etc. Or just tailor it to a particular type of user.

Personally, I feel the Live CD/DVD deals with folks who just want to see what it's like before "risking" the media on their machine.

Will the host be routed? If not, then certain settings are not necessary. And, others might need to be changed (e.g., the default NTP servers).

Identify the type of user/site that you are trying to set up so you can figure out what NEEDS to be done, there.

 

[hasbeen]

My question would be what is FreeBSD used for and by whom.

Personally, as an enthusiast, I use FreeBSD on a desktop and laptop computer to learn about the system and its inner-working with available computer languages and scripting utilities. I install and test all types of software applications and TCP/IP servers. I create documents, images, videos and surf Internet using GUI and CLI network tools.

In both cases, I utilized FreeBSD for all my daily personal computing needs and wants, except for PC gaming and some specialty apps that most likely will never be ported to *BSD or even GNU-Linux. That said, I'm more than satisfied with the current state of FreeBSD - hardware/peripheral support, performance, installation process, system's structure, configuration options and software application choices. Other than splitting FreeBSD into some kind of specialized distributions to perform narrowly defined tasks, I don't see a reason to over-engineer FreeBSD for general use with more automagic and automation or fancy GUI check boxes and sliders. More drivers to support more and newer devices, it's fine with me.

 

[Deleted member 81054]

My question would be what is FreeBSD used for and by whom

I think the notion of a "laptop and desktop" group suggests the target is folks who are likely "generic" computer users who end up sitting at a windows desktop because it is the EASIEST thing for them to do.

THIS machine runs W7 (x64). When Firefox eventually abandons it, there is little chance that we will "upgrade" to W10, 11 or whatever the soup-du-jour!

OTOH, I have rsisted running any FOSS on it because my other half would find it intimidating to learn "a whole new way of doing things". (i.e., there is more to life than just a browser and MUA -- even if that is the reported use of the box).

I don't see much value in addressing the needs of folks who want to "tinker"; they've already expressed the idea that the box is entertainment, of sorts, for them (or a learning opportunity). But, the vast majority (?) of users just want it to WORK. They have no interest in understanding why it DIDN'T work or why some_feature is the greatest thing since sliced bread.

They don't want to have to dick with recovering a broken array. Or, knowing where to point their resolver.

How many people have ANY interest in how their car gets them from point A to point B? Insert fuel, here; activate ignition; press accelerator (and, occasionally, brake). They want FEWER oil changes, tire changes, battery replacements, etc. -- because those things are seen as overhead... COSTS of using the vehicle.

The same mentality applies to many (most?) computer users: what button do I have to push (icon to click) to do X? Why do I have to click TWO???

 

[T-Aoki]

I don't want FreeBSD installer to be target-specific. Ideally it would be better generic, for from beginners to near-experts (real experts wouldn't need installer but create scripts for automating their specific needs instead).

Target-specific installer would be the job for derivated distros like GhostBSD, and FreeBSD as base OS needs to provide the basis for them. And my current guess about bsdinstall, which is heavily script-based, is to achieve it. Just already-implemented scripts/configurations are not yet enough as it is still under developememt.

And don't forget that even on ancient PC-(MS-)DOS, some CUI based apps had window (popup) and supported mouse operations if connected and driver is installed.

 

[Deleted member 81054]

I don't want FreeBSD installer to be target-specific. Ideally it would be better generic, ...

The fact that some apps are packaged with the distribution medium suggests someone has already imposed a bias on the types of things a user MIGHT want.

This is the COMPLETE NetBSD install process. You get a set of core system tools and have to install (or build) packages for anything else. But, when you are done with the install, you should have a bootable system (I've never used a wireless interface so can't comment on how well that works).

My biggest gripe has to do with the "shortcuts" used in the various menus. In particular, the choices assigned to the "setting partition sizes"; its easy to get confused thinking 'x' is the actual partition being specified when it is merely the shortcut for the partition in the list presented (e.g., I keep 'd' as "whole disk" and 'c' as "NetBSD partition (portion of whole disk)" -- for hysterical raisins. So, using the menu leaves me with a disklabel that isn't what I really want (but, I can manually edit it, in subsequent screens)

[It would also be REALLY NICE if I could invoke a calculator -- even if on another VTY -- to do the partition arithmetic! (though you can use some symbolic references in the editor -- like typing 'a' for the start of a partition means "use the endpoint of a, here"). This is really handy!]

 

[T-Aoki]

The fact that some apps are packaged with the distribution medium suggests someone has already imposed a bias on the types of things a user MIGHT want.

Currently it would be dvd ISO image only that contains pkgs from ports.

If I recall correctly, FreeBSD distribution contained most of official packages (except some too large ones) in CDROM image for convenience, as the number and sizes of packages were much smaller compared with current shape. And more, Internet was not as fast, stable, available to consumers as now to download every packages from official site.

Not sure how currently available pkgs in DVD image are chosen.
I'm not a member of release engineering team nor even a committer.

But it should be curated because even DVD would be too small to store ALL pkgs which are not restricted on distribution.

This is the COMPLETE NetBSD install process. You get a set of core system tools and have to install (or build) packages for anything else. But, when you are done with the install, you should have a bootable system (I've never used a wireless interface so can't comment on how well that works).

Looks interesting. I recalled sysinstall, though. Old memories.

My biggest gripe has to do with the "shortcuts" used in the various menus. In particular, the choices assigned to the "setting partition sizes"; its easy to get confused thinking 'x' is the actual partition being specified when it is merely the shortcut for the partition in the list presented (e.g., I keep 'd' as "whole disk" and 'c' as "NetBSD partition (portion of whole disk)" -- for hysterical raisins. So, using the menu leaves me with a disklabel that isn't what I really want (but, I can manually edit it, in subsequent screens)

Brief but sufficient help screen would be strongly wanted. For example, newbies would be confused (me too confused when I was a newbie) about "slice" and "partition" on MBR scheme. Now, GPT era, too wild but understanding "slice" as the equivalent of single, whole drive partition in protective MBR would be sufficient to understand IF THE PERSON ALREADY KNOWS ABOUT GPT.

[It would also be REALLY NICE if I could invoke a calculator -- even if on another VTY -- to do the partition arithmetic! (though you can use some symbolic references in the editor -- like typing 'a' for the start of a partition means "use the endpoint of a, here"). This is really handy!]

bc(1) on dedicated vty?

 

[Deleted member 81054]

If I recall correctly, FreeBSD distribution contained most of official packages (except some too large ones) in CDROM image for convenience

The Wanut Creek (are they still around?) products -- 4 discs per later release -- contained all of the x86 packages, IIRC (I could drag one out to check but I am busy making dinner). But, ages ago, downloads were slow so mailing a few extra CDs to each subscriber was a small cost to pay.

...about "slice" and "partition" on MBR scheme. Now, GPT era, ...

Exactly. Or, NetBSD's notion that a "port" is an architecture (FreeBSD initially being solely 386). Why not "F1" (or some other key binding based on an examination of termcap) to pop up a HELP window -- that could overlay the entire screen, if necessary (as you could make it disappear just as easily!)

bc(1) on dedicated vty?

Why not sh(1) -- already running -- on a dedicated VTY! Why limit me to what I can do WILE the installer is still active? E.g., let me use "dmesg | grep" to find the probe() of the medium (so I know geometry and total sectors), then bc(1) to verify that the starting sector of the "last" partition + its size gives me that exact total. Etc.

Currently, when building a system, I telnet to another running system so I can have the tools that I want handy -- even if not running on the new host:
"Hmmm, which partition did I mount as /usr/pkg? And, how big was it -- so I don't come up with a bad estimate and have to rejigger the label, later?"

 

[kpedersen]

The goal isn't to "impress" but, rather, to make the installer easier to understand in its actions, mistakes, etc.

Indeed. I'm not sure why you brought up the term "impress". A more suitable term would be "setting expectations" or "hiding technical details".

I'm also not sure that a new user needs to understand the installers actions. Its not like if the installer gets something wrong, they can just dig in and fix it. Yes the more advanced installer should (kind of similar to smit on AIX), but for beginners (for better or worse), they expect what they already have on other platforms (clicky Windows-style interface, with some basic questions and "done") and that they can remain isolated from the technical details. And in many ways this is why I don't feel why such an installer can yet be provided (cleanly) for FreeBSD.

(sigh) And folks lament Microsoft's "bloat"...

Hah, check out the size of the FreeBSD installation CD-ROM's (-disk1.iso)

Index of /releases/amd64/amd64/ISO-IMAGES/14.1/

Its so big (even after removing all packages), that it defies the laws of technology in terms of standard cdrom size.

 

[Deleted member 81054]

Indeed. I'm not sure why you brought up the term "impress". A more suitable term would be "setting expectations" or "hiding technical details".

"Impress" need not be a visual thing. I am impressed when "things just work", regardless of what they "look" like. Colored screens and dancing icons aren't "impressive". Something that works without a hitch is! By way of example, I installed ESXi on the machine mentioned below in a matter of a few minutes. I htink there may have been 5 parameters that I had to specify (IP, FQHN, DNS, etc.) and then I could talk to it via a browser and build VMs.

I'm also not sure that a new user needs to understand its actions. Its not like if the installer gets something wrong, they can just dig in and fix it.

First, not every user will be a novice; there will be folks from other FOSS products who know what SHOULD be happening (in the general sense) but likely rely on the installer to handle any issues with which they be unfamiliar. E.g., I've been running a BSD since the Jolitz's 386 patch kit. Yet, the installer left me scratching my head wondering what SPECIFICALLY it was attempting to do (and failing at) and what SPECIFICALLY I would have to do to work-around it's problems.

For example, NOTHING pointed me to the fact that my SAS controller was not enabled (would I know which device driver was associated with it so I could scroll through the probe() messages -- how? -- to verify it was detected?). I was not aware of this until attempts to scrible on the disk failed -- regardless of any changes I made prior to that point. No complaints while setting up the partition tables -- likely because it had just gathered information from me and hadn't yet tried to partition the drive and build the filesystems. Someone with less experience would likely have kept hammering away -- or given up completely!

Second, it provides more detailed information that can be used when requesting help:
"Start the installer. Wen you get to the trouble spot, press ALT-F4 and tell us what the screen says..."

We've discussed ways that this information need not be visible to EVERY user. But, HIDING it from every user is equally bad.

Remember, folks are likely to use a machine that they have decided is "available" and not necessarily a "recent purchase". So, you can't assume anything about the types of problems they may encounter in that "clickety-click" install!

 

[T-Aoki]

Indeed. I'm not sure why you brought up the term "impress". A more suitable term would be "setting expectations" or "hiding technical details".

I'm also not sure that a new user needs to understand the installers actions. Its not like if the installer gets something wrong, they can just dig in and fix it. Yes the more advanced installer should (kind of similar to smit on AIX), but for beginners (for better or worse), they expect what they already have on other platforms (clicky Windows-style interface, with some basic questions and "done") and that they can remain isolated from the technical details. And in many ways this is why I don't feel why such an installer can yet be provided (cleanly) for FreeBSD.

Just my thought, but allow viewing what's going on for newbies, too, is not a bad thing.

As far as I know, most GUI installers hides them and shows (at maximum) so called progress bar. But for something large to install, it often seems to be "frozen", but actually many things are going on in background.

Showing details (optionally) would make users easy. "Ah, this computer is not frozen!"
Here, it is not so important that the user can understand what's actually going on. It's a kind of "chicken and egg problem".

What's important is not to mis-lead the user to feel the installer stopped working. The installer should respond junt in time the user does something. For example, switch from installer screen to log screen, back and forth.

Another thing to avoid mis-leading would be about mouse operations.
On vty, FreeBSD shows mouse cursor if mouse is attached and moused is running. This would make the user to think "my mouse SHALL work on clicking menu items, selecting example and copy it into actual input field SHALL work!". So installer would have 2 options. Avoid moused to run and avoid showing mouse cursor, or support mouse operations all over the installer, even on CUI. Of course, the former is much easier.

 

[kpedersen]

"Impress" need not be a visual thing. I am impressed when "things just work", regardless of what they "look" like. Colored screens and dancing icons aren't "impressive". Something that works without a hitch is!

I don't disagree but this clearly isn't enough for the newbies. The current installer provides this and yet people are still suggesting it isn't inviting to beginners.

First, not every user will be a novice; there will be folks from other FOSS products who know what SHOULD be happening
[...]
We've discussed ways that this information need not be visible to EVERY user. But, HIDING it from every user is equally bad.

Indeed. Hence my mention of a smit like installer for advanced users. Not sure if you are familiar with it or not but smit (or smitty for X11) basically provides a nice(ish) GUI tool for carrying out tasks, but actually lists out the underlying command (or edit) that it is going to perform. That way a newbie can just mash buttons, whereas someone more experienced can check and confirm what it is going to do before executing it (and they can later use the same command as part of a script, etc).

The question is can an installer even be developed which keeps both sides of the camp happy? I don't think so. I don't think FreeBSD will ever be appropriate for newbies (or at least casual users who don't want to learn).

 

[T-Aoki]

The question is can an installer even be developed which keeps both sides of the camp happy? I don't think so. I don't think FreeBSD will ever be appropriate for newbies (or at least casual users who don't want to learn).

It would be technically possible, if properly designed layers are implemented.

Splitting UI layer, define layer-by-layer API (regardless the type. Buses like dbus/invoking command with pipes, and so on) and implement wanted UIs (CUI/GUI or "audible" UI). Making underlying layer needless to know what their outputs are rendered, per vty, per window (CUI/GUI), per different voices.

Ah, I've completely forgotten quite, quite important thing, accessibilities.
So I've listed "audible" UI as an example. Voice recognitions in various languages (maybe Japanese would be one of the most difficult one, I guess) would be strongly wanted, too. Of course, not at all limited with FreeBSD, though. My thought is that implementing it on hardware or firmware level and make it possible to use it on ALL possible OS'es which can run on the hardwares/firmwares as runtime services/BIOS calls are mandatory. Making this kind of things OS dependent is crazy.

Of course, whether we have enough human resources to do so or not is comlpetely different problem.

 

[Deleted member 81054]

I don't disagree but this clearly isn't enough for the newbies. The current installer provides this and yet people are still suggesting it isn't inviting to beginners.

For folks who TRULY are newbies, there shouldn't be options regarding partition editing, etc.

"We are going to use the whole disk, it's going to be split into N partitions that WE think are appropriate. Give me your name -- and a password -- so we can create a user for YOU. We'll add you to the group of users who can temporarily increase your priviledge level (root). Set the date/time - if you don't like what we THINK the date and time are, presently. And, this is what we are going to install..."​

If they want to step in and refine any of these choices, great. But, if they don't, then they get a "nominal system" configured to fit on their hardware.

E.g., I really dislike a giant root partition. So, unless the drive given is tiny, figure out what a good "nominal" root partition should be and how to divvy up the rest so it is most useful to the newbie user (e.g., so he can install the most packages without having to rejigger the partition scheme). This so you can develop rescue instructions that ensure the essential tools are present on that smaller root partition while minimizing the likelihood of IT being corrupted.

Look at how windows reduces the user's choices during installation. That process boils down to watching a bunch of progress bars -- each one letting you think it tells you how close to "done" you are... only to be followed by another!

If, while this is happening, I could switch to another VTY and watch what's REALLY happening, then the non-newbie can see what's involved as well as where it may be getting hung up.

I don't think FreeBSD will ever be appropriate for newbies (or at least casual users who don't want to learn).

I think you can address newbie needs -- just not with an "optimal" installation. Because you won't be able to guess their future needs well enough to make the best configuration choices.

For example, if a machine presents with 4T of disk (or more!), is it REALLY a good idea to treat that as a single partition? Two? Five? Any choice you make will end up "hurting" some newbie in some situation. I run 6T on each of my Windows workstations. But, deliberately put "read only" items on separate drives so I never have to back them up (I can always reload them from their original media!) Experience taught me to separate out those things so my backups would be smaller and faster (and, that sort of stuff rarely got compromised).

My BSD boxes run with 14 partitions -- because I have found that to be the best way to make use of the media for the uses to which I put them. As a newbie, I would have found it difficult to make that decision -- as well as settling on sizes for each of them!

My other half is perfectly content with the default Windows wallpaper on her workstation: "It's always covered; what do I care what it looks like?!" OTOH, she likes to increase the default size of the typefaces to make it easier to read. (But, figuring out how to do so required assistance)

 

[astyle]

Don Y : Y'know, these days, nobody cares if it's a laptop or desktop. They run the same stuff, and have about the same amount of power.

About 20 years ago, laptops were seen as 'less powerful than desktops', so the distinction was important. But these days, you can have a laptop with 40 GB of RAM and a real Ryzen than compiles GCC in about 2-3 hours. If you need a big screen, just plug in any recent TV via HDMI, and you'll be fine, even on FreeBSD.

Besides, why is there a need for you personally to be impressed, Don Y ? You know how to do your own homework, you can find what you need - how about trying to step into a field that you know nothing about, and realize that even trying to pretend that you know even something will get you into serious trouble? That's what people new to UNIX are facing.

 

[cracauer@]

Don Y : Y'know, these days, nobody cares if it's a laptop or desktop. They run the same stuff, and have about the same amount of power.

About 20 years ago, laptops were seen as 'less powerful than desktops', so the distinction was important. But these days, you can have a laptop with 40 GB of RAM and a real Ryzen than compiles GCC in about 2-3 hours. If you need a big screen, just plug in any recent TV via HDMI, and you'll be fine, even on FreeBSD.

Nah, the laptop chips, CPUs and GPUs, are still way behind. They just hide it by giving them designations that leads people to think they are comparable to specific desktop chips that are in fact much faster. Especially under contiguous load (heat throttling).

 

[Deleted member 81054]

Don Y : Y'know, these days, nobody cares if it's a laptop or desktop. They run the same stuff, and have about the same amount of power.

They are different experiences. I typically see laptops stashed in a kitchen drawer and used on the kitchen counter -- briefly -- then stashed away, again. Now, I see folks using phones for things that were often done with a laptop. People seem more inclined to "upgrade" their desktops than to upgrade a laptop -- there is less that is "upgradeable". And, laptops tend to be far more disposable (keyboards get damaged, screens start getting defects, you lose the power adapter -- or its output cord gets gnarly, etc.)

You also are less likely to have many peripherals hanging off a laptop beyond a printer or maybe an all-in-one. An "advanced" user may want to support a DAS or iSCSI, multple monitors, motion controller, etc. Largely because a desktop becomes a workSTATION whereas a laptop is just a portable computer.

My smallest machine has 96G of memory and 12 cores. Presenting me with an installer that limits my choices (to be compatible with those of a laptop user) would cause me to look elsewhere.

Besides, why is there a need for you personally to be impressed

"Impressed", in the sense that I quoted ("it just works"), should be the goal of EVERY product. Unless you don't care about people actually USING your product! You definitely don't want folks coming away from the experience complaining about what a dog it was!

how about trying to step into a field that you know nothing about, and realize that even trying to pretend that you know even something will get you into serious trouble? That's what people new to UNIX are facing.

Every product I've ever designed was in a (different!) field about which I knew nothing prior to beginning the work. But, I acknowledged that deficit and took action to overcome it BEFORE exposing myself (and my client/employer) to a loss.

Do you know how tablets ("pills") are made? Do you know what the regulatory issues regarding their production are? Do you know what the issues involved in the physics of their manufacture are and how they impact the quality of the resulting product? Do you know how they put the "coating" on (some) tablets? Do you know WHY?

Do you know how LORAN navigation works (past tense as I think the last chain has been decommissioned)? Do you know how to convert TDs to (lat,lon)? Did you realize that the Earth is an OBLATE sphere? And, how much so? And, how this complicates the spherical geometry used for said conversion? Do you know how the precision of the system varies based on the chain's geometry and your physical position (Geometric Dilution of Precision -- GDoP)?

Do you know how to tune a PID loop? Why each term is present? The consequences of each?

What about gaming (gambling) devices? Do you know where you can display playing cards as if they were just abstract symbols (like cherries) and where their use must conform to the expectations of a deck of cards? (FIVE kings???)

Etc. And, in each case, there was real money at stake (e.g., if I crash a boat on the rocks because my "math was wrong", folks could lose their lives) if I failed to act with incomplete or inaccurate knowledge (and my employers were sure not going to wait around while I "learned").

The downside of incomplete knowledge with a desktop (or laptop, if you prefer) is just inconvenience or frustration. To an advocate, it may be a "lost (zero dollar) sale".

People face challenges every time they try something new. At some point, you have to assume they are responsible individuals and stop trying to hand-hold. ("We'll take the TRAINING WHEELS off the car, sometime next week...")

 

[astyle]

You also are less likely to have many peripherals hanging off a laptop beyond a printer or maybe an all-in-one. An "advanced" user may want to support a DAS or iSCSI, multple monitors, motion controller, etc. Largely because a desktop becomes a workSTATION whereas a laptop is just a portable computer.

Printers and other cable-attached stuff are on their way out, everything is done over wifi or infrared. Even CUPS is now AirPrint-compatible, and I wrote about that on these very Forums With an app, my phone is my TV remote.

My smallest machine has 96G of memory and 12 cores. Presenting me with an installer that limits my choices (to be compatible with those of a laptop user) would cause me to look elsewhere.

The FreeBSD installer doesn't care, it will see those no problem. Hell, FreeBSD supports up to 128 cores, and there are users on these Forums who had no issues using the same installer on an Epyc and on an Athlon. Please do provide screenshots where the installer should have seen more powerful hardware, but didn't. wi-fi (where there's support only up to 11g speeds even if the card is AC/AX) doesn't count.

What about gaming (gambling) devices? Do you know where you can display playing cards as if they were just abstract symbols (like cherries) and where their use must conform to the expectations of a deck of cards? (FIVE kings???)

I do know about gaming devices, I own one (Asus ROG Zephyrus with a Ryzen 9 6900, 16 GB of RAM and a discrete GPU). Yeah, it can run hot at times, but it compiles stuff pretty well and fast, very usable as an R&D machine, it has no issues gaming or virtualizing, either.

Do you know how LORAN navigation works (past tense as I think the last chain has been decommissioned)?

No, I don't. I just buy my plane ticket, prepare travel papers, and make sure I pack within international safety regulations. I don't have to know about navigation and rules of flying, I just leave that to the pilot. It does help to know that you can't exactly drive to Hawaii, but that's about it. But I've seen plenty of stories about people who seriously had no idea that there are no trains to Hawaii. And I've seen plenty of stories about people who pretended to be knowledgeable (when in fact they were not), tried to show off, were rude, and ended up getting booted off the plane for their behavior.

 

[astyle]

Etc. And, in each case, there was real money at stake (e.g., if I crash a boat on the rocks because my "math was wrong", folks could lose their lives) if I failed to act with incomplete or inaccurate knowledge (and my employers were sure not going to wait around while I "learned").

I remember ralphbsz had an interesting post where he told the story of someone who was asked to write an accounting app. After a couple years, the boss asked the programmer, "Well, how is it coming along?". The programmer replied, "I am still writing the Great American Compiler, which will then be used to write that app".

 

[Deleted member 81054]

Printers and other cable-attached stuff are on their way out, everything is done over wifi or infrared. Even CUPS is now AirPrint-compatible, and I wrote about that on these very Forums With an app, my phone is my TV remote.

Do you think people LIKE having to replace kit that they bought "a couple of years ago" because their newest PC/laptop/phone can't deal with it?

Please do provide screenshots where the installer should have seen more powerful hardware, but didn't.

IIRC, the box in question has a PERC H730(?) in it. The GENERIC/INSTALL kernel won't recognize it without setting a switch in sysctl. Of course, IT didn't tell me this -- despite being able to at least partially use the interface (to tell me how many drives I had and the capacities of each!)

I do know about gaming devices, I own one

"Gaming" is how the GAMBLING (note my parenthetical annotation in my post) refers to itself. It is a regulated industry (except for the "grey markets" -- which aren't supposed to exist)

I don't have to know about navigation and rules of flying, I just leave that to the pilot.

... because the pilot (or skipper) is relying on devices that DO know about those things. Do you think those devices just magically appear because someone decides they need one?

"I am still writing the Great American Compiler, which will then be used to write that app".

So, who's to blame? The developer for his chosen approach? Or, the guy who HIRED him (mistakenly?)? Or, the guy who underestimated the complexity of the task?

 

[aji_pineapple]

I'd love to help and provide a new user's perspective. I just started using FreeBSD on my laptop just over a month ago. The install process was actually very smooth, easier than Arch Linux which I used before this. The documentation is very good. The only part which was a but confusing was I couldn't use the automatic partitioner for ZFS if I didn't dedicate the whole disk. A lot of people including myself dual boot Windows for various reasons. Wifi management could be a bit easier.

One suggestion is to automatically install a light weight GUI. OpenSUSE has a generic desktop option which installs IceWM. I started exploring IceWM because of that and loved it. Its the WM I use 90% of the time. Once the user is on a simple GUI they can choose the DE of their choice.

And please, please, please install a user friendly text editor like micro by default. Lets not subject another generation of *Nix users in the 21st century to shortcuts from the 1970s and 80s. This will put people off adoption of the OS.

 

[Deleted member 81054]

And please, please, please install a user friendly text editor like micro by default. Lets not subject another generation of *Nix users in the 21st century to shortcuts from the 1970s and 80s. This will put people off adoption of the OS.

This is probably a sore spot. Vi, ed, emacs, etc. tend to have "staying power" in that you can move to almost ANY Un*x system and find one available for use. Given the number of text files that are used to configure the system, you want to KNOW you will have something available that you KNOW how to use.

The risk of adding another is that it can lead to deprecating the old tools. Fine if you never have to leave your system-of-preference but disasterous if you find yourself somewhere that doesn't offer you that particular tool.

[E.g., I make a point of keeping my root partitions small. Tiny! Less exposure to potential damage. As a result, almost all of /usr is unavailable to me if I have to boot single user for a recovery operation (i.e., no /usr/bin/vi!). Nothing dynamically linked. No GUI, etc. Yet, /bin/ed is there to get me through the pain...]