It's a chicken-and-egg problem. Server hardware comes with VGA, because everything in the server room (think KVM switches, external remote KVM, local 19" consoles) is built with VGA. And that will be the case as long as server hardware comes with VGA.
I will be very surprised if it doesn't start switching over to USB-C over the next decade or two. Having a single port capable of doing the entire local KVM dance using readily-available hardware is just a no-brainer.
Some switches have already started using USB-C for serial instead of RJ45. When the technician is 100% already carrying a smartphone and C-to-C cable to charge it, making the console available with zero additional adapters is quite attractive.
So, display out from USB-C cable is not display signal over USB 3.x digital signal, it's just an electronic analog patch-through to GPU. The pins in the port actually run raw DisplayPort signals when that feature is activated. So you can't plug a laptop to a server and get nicely packetized screen frames out over the USB host hardware. This is often not clearly communicated...
You can put a USB to RS232C or USB to Ethernet adapter behind the port to then expose ttyS0 or to serve a management webpage, that could happen, but I think the DB-9 and/or RGB would have to stay in that case.
ARM has better software support for AI applications and half of their presentation was about their inference accelerators that can go in the mainframes (and POWER machines).
IBM mainframes are almost designed by their users. The previous generation skipped a lot of speed boost on the CPU side because their users didn’t want the machine to blow over their power delivery limits.
Now, with their architecture behind it, I’m sure these ARM Linux partitions will have the fastest ARM cores ever made. My experience with Linux on s390x is that it feels like a normal server that’s just ludicrously fast - almost as if it came from the future.
Mainframes are exquisitely "balanced" machines that match processing capacity and IO for a relatively small set of workloads. You won't see mainframes doing scientific number crunching or AI training, but you'll increasingly see them adding more AI inference into their transaction processing workloads for things like fraud and anomaly detection. While their CPUs are prodigiously fast (the one announced is designed to run at 5.7 GHz, and the cores themselves are huge compared to other architectures), a lot of emphasis is placed on the IO systems that connect the machine to storage and other systems so that the CPU is busy all the time. It's very normal to run a mainframe at close to 100% CPU utilization.
The funny thing is that Fujitsu has a sizable enterprise IT business, and their Primergy servers are very good, so why don't they offer their own ARM CPUs?
At least back in the day, there was talk about Nvidia + ppc64le. Wasn't there even a supercomputer with that setup? But I guess that has fallen by the wayside.
We have some older Power9 with NVIDIA V100. Nvidia drivers stopped a while ago (before V100 were considered “old” also for x86_64).
The main problem is software support by most machine learning libraries. While it is normal to have to compile many things from source when the binary is not provided even by some third party, in some cases the software will not compile on ppc64le and surely is not tested to work.
I would probably suck at marketing, and my personal preferences and convictions have no bearing here, I guess.
With that out of the way, I hate this kind of vague messaging. Yeah, the product will... somehow enable me to achieve some vague goal. Okay. Why don't you slap some screen-filling pictures of happy people in an office on there while you're at it, Mr. Marketing. I'll probably just close the tab and move on. I need substance and details, and I don't have the patience to go digging in your stupid feel-good marketing material for 20 minutes!
We need reliable, real-world ~20mbit/s for our warehouse scanners, not 382722 theoretical Gbit/s 5cm from the access point. And roaming that works instead of stupid clients clinging to somewhere or being thrown into a reconnect loop when the AP tries to get them to roam.
I know this is theoretically possible today. But in the real world, I have inherited the setup, so AP locations are fixed for now, clients are some random old handhold motorola android devices and interference is high.
In comparison, DECT has been flawless in the same space. Set and forget, just works. I always wondered if we could have a kind of DECT proxy on the LAN, and have the ERP application talk to that proxy using DECT... I mean, it's a few EANs and stuff, DECT could handle this easily.
I was recently made aware of WiFi HaLow. Official standard, ranges into the hundreds of meters. Speed suffers at long ranges of course, but still respectable (50-100kbs).
We have devices sending telemetry and occasional OTA updates without urgency (if it takes a few hours to get it over it’s not a problem).
If you need consistent MB range traffic for cameras I wouldn’t advise it but for low (5kbs) traffic it can be attractive. A few thousand bits can encode quite a bit of information. Don’t be fooled by the “kbs”.
The problem is that the application of the rules is inherently usage-specific.
For example, with the 1% duty cycle limit it is totally fine to have a transmission take 30 seconds - provided you only send 1 transmission an hour. Want to send one transmission per minute? You'll have to get your transmission time down to 0.6 seconds. And your transmission speed is inherently linked to your data rate, and by extension your signal range.
There's no one-size-fits-all solution possible here. Either the user has to give it some information about their specific use case, or it'll have to stick to the absolute most pessimistic limits.
The ETSI document actually does allow higher duty cycle if the radios take anti-interference measures. Some countries unfortunately have "harmonized" but skipped that part. Theoretically only a dumb transceiver (that can utilize only a single channel) has to limit duty cycle that low in those bands.
Dead outside the US unfortunately, worse range than regular wifi due to being strangled by lower channel width and ridicolously low power limits. The two bulky HaLowLink routers are the only off the shelf thing with support for it, it's nonexistent as a wifi standard.
I was so excited when I discovered it a few months back after struggling for years to set up reliable wifi for outdoor robotics, only to realize we can't have nice things. The struggle continues.
No I mean the total frequency range is much smaller. The US has 26 MHz width, while EU/Africa/India only allocated 7 MHz total. The difference in absolute frequency is minimal at ~30 MHz, you almost get more difference from using different channels in the US. What affects range even more is that in the US you can transmit at 1000 mW vs. 25 mW, so the end result is about ~5-10 km vs. 100-200 m. At that range 2.4 GHz is king and stomps it at over four times the allowed power to transfer ridiculously higher amounts of data.
Don’t know about the parent, but I found LoRa adequate for (tiny) payloads (sensor data and such) but OTA updates are a PITA without some alternative channel. Speeds are measured in bytes / sec.
Perhaps you can try DECT NR+ the new reincarnation of DECT and also backward compatible with the original DECT [1]. It can also do roaming.
It's under 5G standard but for non-cellular connectivity that means you can use it without base-station like Wi-Fi direct. It's geared toward IoT but its data rates are from 1 Mbps up to 1.3 Gbps depending on the operating frequency and the type of modulation being used [2].
[1] DECT NR+: A technical dive into non-cellular 5G (30 comnents):
Here's another one for you: today I found out that my dual-sim android phone has a single radio that is shared between the two sims. So when you are on a call, the 4G/5G doesn't work on the other sim, likewise, sometimes the the voice sim is unavailable while the other sim engaged with 4G/5G things... which is just stupid. Can't they just add two radios/chips (like many wifi AP's....)? So the whole setup on a consumer phone is actually quite unreliable because of reusing a single radio. I thought it was my buggy code, but nope, just the radio being shared and the mobile operator seeing the sim as offline. Crazy.
I can't speak to your specific setup, but if the two SIMs use different carriers then they will often need to use different frequencies. A phone could in theory use twice as many radios, but the emitted power limits would be the same, so you'd have reduced range or throughout for each (plus additional size, weight and power for the second radio). Access points have different SWaP budgets than phones.
When I travel, I try to use an eSIM that uses a network my home provider partners with. This seems to improve the chance that voice and data over LTE or 5G NR work simultaneously.
Dumb question: If the limit is L, why do regulators care if I have one device with two radios each outputting L or if I have two devices each with one radio outputting L. Either way, total output is 2L.
What is the objective?
* To limit range? Then regulators shouldn't care about 2 radios in one device outputting L, as long as one radio doesn't output 2L.
* To avoid cooking nearby electronics and people? How do they account for the unpredictable, theoretically limitless number of devices in an area? What about someone working in a cell phone store or passengers on a Tokyo train at rush hour? Do regulators just set L low enough that any realstic number of devices together is safe?
Usually, the exposure limit is based on an active phone next to an ear. RF field strength falls off with the square of distance, so a phone on each side of your head is most dangerous to the respective ear and bits of your brain close to your skull; each phone is considered acceptably safe to the middle of your brain and the opposite ear.
Common dual SIM configuration eTLA(extended three-letter abbreviations) are:
- DSDA: Dual SIM Dual Active, theoretically can call and do everything on both SIMs simultaneously
- DSDV: Dual SIM Dual VoLTE, can standby on both at all time but can't "use" at the same time
- DSDS: Dual SIM Dual Standby, can standby on both on so long radios don't conflict(3G+4G|4G+5G)
- DSSS: Dual SIM Single Standby, can physically mount two SIMs to just electronically switch between
It depends on the phone. The rule of thumb in the past for typical dual-SIM phones was nG on the first SIM, n-1G on the second. Then, after you encounter that for the first time, you make sure that your next phone has a baseband that supports nG on both SIMs, although with 5G it's become a bit blurred, typically 5+4 or 4+4, not that that makes any difference (5 vs 4 I mean).
Yep, although (at least in my experience) it's not enabled by default. I also learnt about VoWiFi (also called "WiFi Calling") that allows you using WiFi for calling, including when you're abroad or you don't even have phone signal.
Support for VoWiFi is a bit weird. Some operators don't allow it outside of your region (for example, the EU), some others will allow it and even bill you as if it were a local call made from your country.
Also, although it's in theory made only for working through WiFi, seems like if you have a second SIM or eSIM with a data plan (for example, a travel SIM local for the country you're on vacations) and some combination of phone and/or operators, it can use the second SIM as the data provider for WiFi Calling.
For the major US carriers, since they shut down 3G, VoLTE is the only way calls work. Which meant that a non-VoLTE-but-4G-capable device can no longer make 911 calls.
I was using a Samsung S5 running LineageOS for a while with Google voice for calls, but the no 911 thing is one of the main reasons I finally moved to a different phone. The S5 supports VoLTE but only with stock firmware.
Auch, wasn't familiar with that, haven't been in the US for a while. At least around here (EU) is not enabled by default on phones you buy off the shelf. I'm not sure about phones bought from the carrier.
What part of EU doesn't have VoLTE enabled? It is definitely widely used here in Sweden, though they simply forbid phones unable to do emergency calls over WiFi (including existing phones, which forced me to buy a new one. That was very irritating).
To explain myself better: it's readily available on the carriers, but if you just buy an off the shelf phone and put a SIM on it, it won't be enabled automatically (at least in a couple countries I tested it), and you'll need to go to your Android SIM/carrier settings menu and enable it yourself.
LTE was originally designed as a data-only upgrade to 3G. It became the full on successor to 3G, but launched with voice spec left as TBD. It eventually got defined, but ended up being a cursed nonstandard SIP-VoIP software thing, and so a lot of carriers and networks implement whitelists for VoLTE phones to manage anxieties around it.
VoLTE was an advertising feature for a long time. Major carriers here were advertising it as active and available for at least a year before it was actually available.
Not for everyone in many places. Many carriers still only allow VoLTE for a limited alow-list of phone models. Any customers of those with less popular models still gets dropped to 3G calls.
An additional radio would raise the price of your phone for at least another 200 or 300 dollars. Try to enable VoLTE if available for your operator. That makes the phone use the LTE connection for voice and don't drop the Internet connection while you talk.
Dual SIM Dual Active phones are under £100 in the UK, I imagine under $100 in the US.
Dual SIM Dual Standby (two or more SIMs, one radio) is cheaper, less battery, less space, and usually good enough. It's literally a few dollars, not 200-300.
Seems like I forgot to specify "5G" (those radios tend to be expensive) as the original poster was asking for an additional 4G/5G radio.
DSDA in 5G is rare, and I can't reliably find a phone that can do it in EU or US (I can find higher end chipsets that can do it, but phone vendors don't seem to follow through with it). Usually it's 4G+5G or 4G+4G.
I assume for something like a phone these things are non-linear. going from 2 PCIe lanes (nand, radios) to 3 (another radio) may cause an SOC to jump from entry-level to mid-level, larger PCB and increased layer count, more antenna for simultaneous use, etc. so its not just the cost of the chip but all the secondary effects.
A non-linear cost for a small fraction of the phone. A slightly larger PCB with two more layers is about twice the price for the PCB, more antennas is a couple dollars, a one lane PCIe switch is a few dollars if that's cheaper than upgrading your SOC. And if it shrinks your battery 10% you save money on that part.
I blame niche-ness far more than the actual design and production costs.
> PCIe switch is a few dollars if that's cheaper than upgrading your SOC
perhaps you're more familiar with these options than I am, but I see 4 lane PCIe switches are 10x10 mm and maybe they are a few dollars but take more board space, new/larger power supplies, etc so it seems that the costs are more than just a few dollar PCIe switch chip. not sure how many phone PCBs can handle additional 100 mm2 but definitely looking forward to learning more.
add to the antennas are likely based on best/cheapest efficiency for the available area, then additional antenna would reduce the area for each and require more effort/cost.
It won't, but the pre-made platform solution you pick and the prompt you send to Chinese ODM who do all the hard work must specify it has to be (DSDA|DSDV|DSDS|DSSS), or otherwise it'll default to DSDS.
Ironically, the cheapest phones available all tend to have Dual SIM Dual Active, usually because (in Europe at least) many have a second SIM card specifically for international calls.
So yes, it's "too expensive" because it's higher than $0, but it's not "too expensive" as in it would cost a lot.
> or being thrown into a reconnect loop when the AP tries to get them to roam
The AP does not have visibility into what the client actually sees, and no, a coordinator that has knowledge what the APs see isn't that much better.
Imagine a situation with two APs and a client being in the middle of the two in a RF-impeded situation (i.e. your typical office building). AP1 may "hear" the client better (i.e. it gets a higher RSSI and SNR), but the client may reject it in favor of AP2 because the client sees a better signal coming from AP2 due to reflections, a powerful RF signal from a floor above interfering with the channel of AP1 or God knows what else.
Often times the problem is that the client radios are much weaker than the APs radios.
Sometimes we forget that for the communication to be reliable, signal must flow both ways. Clients will happily connect to far away APs, but won't be reliably heard back.
Solution is to use more APs and lower their radio tx power. A lot of customers push back on the approach because they have only one gaming router monstrosity in their country home and it works perfectly, not understanding that their downtown office with 150 devices have nothing in common.
I'm no RF expert, and we're not a big company. I wear many hats, from DBA to local WiFi expert. And while there are certainly limits to what can be achieved without dedicated experts, I want to stress how DECT in the very same scenario just delivers unwavering reliable operation without me ever giving a hoot about RF interference or 802.11k or r or any other implementation detail.
> And while there are certainly limits to what can be achieved without dedicated experts, I want to stress how DECT in the very same scenario just delivers unwavering reliable operation without me ever giving a hoot about RF interference or 802.11k or r or any other implementation detail.
DECT is a much, MUCH more old, simple and robust protocol. Modern signal processing tech can get you insanely far there.
This has been a solved problem in the land mobile radio world for a number of decades.
You have a bunch base stations forming a logical channel with a single uplink frequency, and either a single downlink frequency on which every base station is precisely synchronised in frequency and time (simulcast), or multiple downlink frequencies (a multicast system).
A comparator selects, or votes, the highest quality signal from the base receivers based on either lowest noise or lowest BER, and then repeats that through all of the base transmitters simultaneously.
At the same time, in a multicast system, the mobile scans for and selects the base transmitter with either the highest RSSI or lowest BER.
How much money do you have? Nokia's Centralized RAN basically solves for cellphones by not choosing between AP1 and AP2. The device yells out a packet, both radios hear it, and the signals are combined in baseband processing. Wifi 8 doesn't quite do this, maybe 9's gonna have it. Or the patents run out and the telecom networks cooperate and everything gets a cell modem.
I've had similar issues with clients (Blink camera sync modules) connecting to far-away APs instead of the much closer router. I could not force them to connect directly to the router no matter what.
Turns out the 2.4 GHz radio of my router had died (Fritzbox 7590, apparently a common issue), thus forcing 2.4 GHz-only clients to use those other APs.
In ubiquity gear you can “lock” devices to a specific endpoint. I suspect ultimately you would prefer to have failover available but at least for troubleshooting you can see how it connects to that specific AP. Similarly you could see the amount of clients connected to an AP on every frequency and WiFi version.
You can ban devices from all access points except one. That is not "locking" it to one, it's just preventing it from successfully connecting.
It will still try to roam, it will still cause issues.
A lot of the roaming logic is in the clients. Newer android and iOS versions have gotten better but there are tons of old and new devices with poor roaming logic and capabilities.
And actually debugging this unless you have a bunch of enterprise level kit, or know exactly what the failure you’re looking for is is absolutely impossible
I used Wireless Diagnostics.app on macOS ("Scan" window) and looked for the 2.4 GHz radio's MAC address which was nowhere to be found. But yeah, you have to have a hunch.
Thanks - I’ll try this. I have a problem where my kindle only downloads books in one room (but I can make purchases in any), and I’m pretty sure that it’s connecting to a different AP and doing something stupid in the process
Yeah you can run stuff through DECT I'm not sure what handheld suitable gateway you'd use and strap to the holster of the associated scanner, but otherwise...
That said, in theory at the level you're asking for it'd be acceptable to run the system as a single frequency network by using the AP locations as remote radio heads and just not telling the handhelds that there are multiple APs in listening range.
I'd probably aim for using the wifi support mechanisms to dynamically fake nearby APs as "mimo antennas" from the POV of the handheld, but not doing so would also suffice, just transmitting from the one AP that's nearest to the specific handheld/client would already basically do the trick and could probably run with hacked firmware on commodity AP hardware basically turning the entire setup into a soft-MAC with that very software juggling the army of radios.
The setup btw. would not have the clients aware they're dealing with more than one radio on the other side.
You could be forced to ask/ping the client from multiple APs one after another if you've not heard from it in a while and it moved, but otherwise, you just rely on hearing it from multiple APs and tracking it so you don't have to make APs across the facility speak up and risk interrupting other clients that try to get a word in.
Oh, and ban by building ordinance usage of any other Wi-Fi on the channel your doing this on, or that's gonna eventually get you problems with congestion.
I understand the question and the environment you're alluding to re RF noise and AP distance from clients, etc. in a warehouse environment.
By default clients will always try to connect at the highest wifi standard and link rate, regardless of that connection type's qos level.
I've not seen an AP setup where the wifi standard (a, b, g, N, 5, 7, ...), channel size (20 vs 40mhz), channel, and in some cases speed stepping, couldn't be forced at the AP.
If you force the APs to only broadcast G, each on a specific channel, (literally just an example for discussion) the clients will connect that way if the device radio supports it,while re-using existing auth credentials. No client-side changes are necessary here and thus easy to test. I've encountered device radios that are only 5GHz, but that'd be clear in your testing. Forced AP settings do wonders for wireless networks.
Regarding user's opinions, they may claim to need the latest and greatest but in real life if their network use only needs megabits and the connection type satisfies that, they don't notice. And you don't tell them. :-)
I have already limited the "warehouse" SSID to 2.4GHz, 20MHz channel size and made an optimized channel plan that keeps the neighboring APs on channels manually chosen for minimum overlap. Anything else?
Speed stepping? Reducing the wifi standard looses features like roaming hints and stuff like that, no?
LoRa is quite nice for this in the lower frequency bands, and the bandwidth should suffice for this sorta thing. And the tech is super cheap to build and maintain, both hardware and software is open source.
Maybe read grandparent's comment again? They were talking about using DECT as an alternative and about string encoded EAN codes, not about watching YouTube in 4k.
There are still landlines in use (although they mostly use VOIP instead of analog phone lines). All cheap cordless phones I know run DECT. It's more than enough speed for speech and more stable than wifi.
The AVM Fritz product line of consumer modem/routers all include a DECT modem for registering extra handsets for voice but they have their own proprietary handsets that support TCP/IP over DECT for things like audio streaming or sending extra media like a caller photo.
I've never really liked talking on cellphones and got a grandstream cordless DECT phone that runs over a voip line probably a decade ago. One of my favourite purchases.
Cordless phones have mostly disappeared but the Panasonic Link2Cell models - where the base station acts as a Bluetooth headset for up to two mobile phones - are still around and are absolutely marvelous for older adults. They can plug their mobile phone in to charge and walk around with one of the handsets (a base station can support up to six!) so that if they should fall, they have a phone on them to call for help.
I have a DECT headset and I would never go back to Bluetooth. The range, reliability and the quality of modern DECT is great. Just make sure you get one with ultra wide band or similar otherwise you end up with cordless phone quality.
How much data do the scanners really send backwards and forwards?
I feel like a lot of the problems people try to solve with wifi and dozens of access points could be better solved by a 450MHz-ish transceiver up on the roof with a downfire turnstile, and 9600bps radio modems in everything.
I'm going to embroider some red hats, going to put on them "MAKE SLOTTED ALOHA GREAT AGAIN".
Legacy clients force APs to accomodate them. Be it by using slower speeds with worse airtime consumption or by just disabling features that (can) make old clients misbehave.
Your first paragraph is possible now with most enterprise 802.11ac equipment (Cisco, Aruba, Mist, Ruckus, etc) but it needs to be properly designed, placed, and configured.
DECT is a different frequency and is much less vulnerable to nearby metal, backscatter and so on.
You need to get someone in there who is competent at wi-fi design (I am only marginally so, but I’ve done a lot of learning by failing)
Industrial 5G is super expensive. Also almost impossible to find a vendor that offers all the nice protocol features (Low Latency, native Ethernet tunneling, etc.) in their infrastructure.
We have about 20 client devices, I would very much prefer to throw a bunch of APs into the warehouse and it just works - DECT can do it, so wifi should, too. I'd settle for 10mbit/s!
The issue is that Wifi offers no reliability guarantees and does not scale when number of nodes grows beyond a relatively low number. So when number of nodes is large and you want to perform critical tasks (e.g. control robots, machinery, etc remotely) Wifi does not work.
There's no good reason it can't handle even more nodes, especially since you can have over 50 separate channels. Central control of the frequencies helps somewhat with density but not that much. We can and should fix those flaws.
I don't think I trust 5G for sub-second critical tasks either...
> We need reliable, real-world ~20mbit/s for our warehouse scanners, not 382722 theoretical Gbit/s 5cm from the access point
Those two are the same thing, though!
Literally nobody is hitting those insane theoretical transmission speeds. Heck, most access points don't even have the uplink for it. So why bother? Easy: because it provides you margin. A 10Gbps link degrading to 100Mbps due to poor signal quality is a lot better than a 1Gbps link degrading to 10Mbps when you are trying to achieve that 20Mbps connection. The expectation is that your signal will degrade, so it is all about starting with a good-enough spec that you'll still have a reasonably-usable connection left at the end.
It's a similar story for multi-client connectivity. A 10Gbps link might sound overkill for a 500Mbps residential internet connection, until you've got legacy and poor-signal-quality clients taking of 95% of the airtime for 5Mbps of data. Being able to still get enough data through that remaining 5% airtime to saturate your internet connection is incredibly useful.
And before you praise DECT too much: its 2020 revision allows for a 1.2 Gbit/s transfer rate, with all the fancy stuff like MIMO and beamforming you might know from Wifi. Quite excessive for a few simple phone calls, wouldn't you think?
Yeah it sucks. But it will always be a dance. And the folks that make the clients will always choose “best effort”. Sadly, we can only reduce clients decision so far before things break
My family doesn't know that the WiFi AP is not the DECT base. They understand when I tell them, but that's gone after a week. They use the words WiFi (or, as we say in Germany, WLAN) and "Internet" almost interchangeably. At work, too. "Internet kaputt" can mean anything from "my device is broken" to "our ERP app is not doing the right thing / responding too slow".
That is true everywhere. I think operating systems could do a better job at informing about the health of the internet connection in words the user understands. What seems to be the current bottleneck:
You can’t blame them, though. I live in the industry for over 25 years now, and when 5 Ghz wifi got introduced, and started to live alongside 2.4 Ghz with all the different protocols, I was like: "Nah. Screw it." I honestly have no idea what the current hot stuff in terms of wifi is.^^
> They use the words WiFi (or, as we say in Germany, WLAN) and "Internet" almost interchangeably.
I was helping our neighbor with WiFi issues. They asked at some point if a "WLAN-Kabel" would solve the issue :)
The sad part is that they realized the mistake a minute later, and since I didn't say anything but just answered the question (I understood what they meant, no point correcting the technicality), they assumed that I was just laughing at them behind their back / internally. Turns out once again that tech is as much social as it is technical, and I really struggle with people who think everyone else is hiding something (they vote accordingly, let's say)
It really doesn't help that a part of our attention-economy has hopped on the "what (the government/big tech/car company) doesn't want you to know!11" bandwagon and constantly feeds into this notion that there is this great ominous evil cabal working against you.
For me, it was Gentoo. I was a little bit lost after a bad time in the public school system, and not sure what to do with my life after that. I was fascinated by Linux, but never really got the hang of it. Used SuSE, which was fine, but I never really knew what I was doing. And then I get into Gentoo. Messed up some stage3 installs until it all started to click for me and I had the correct mental models for stuff and how it all fit together to form a complete system. That basically kickstarted my career as a Sysadmin, and I'm still a Gentoo user to this day (but only on the desktop, too much compiling for my laptop...).
I feel very, very grateful to all the folks involved. Of course to all the people behind Linux, but Gentoo especially. In a way, it saved my live. Not sure where I would have landed w/o Linux.
I've also used Gentoo professionally on many occasions, of course for one-off servers that I treated like pets early in my career, but also in a more cattle-like role. Had a custom updater that copied a new stage4 into a "B-Slot" (btrfs subvolume) from a golden master system. That contraption drove about ~25 POS systems for a small retail chain.
Uh, much wasted time for one? Be it due to destroyed filesystems because of ugly hard crashes,
because the optimizations I applied during compiling without really understanding them(at that time) gave me many, many surprises, or the potential of destroyed hardware?
Yes, you could overdrive your screens into magic blue smoke.
Or speaking wrong to some interface-card, say SCSI, or ATA-CDROM.
All of that could happen. I only suffered from destroyed filesystems, though.
It isn't wasted time if you learn something, though, is it? To be fair, as a hobbyist I only ever really experimented as far as I could afford if the hardware broke, and anything too experimental I kept the only version of any data off of (that used to be way pricier in time and materiels though, true).
Sidenote: "AMD Drivers", in the sense of "something you have to download and install manually", are not a thing any more, fortunately. It's just nvidia now.
In Debian, even nvidia drivers are part of the OS repositories, albeit in the non-free category which is not enabled by default. I would be surprised if Ubuntu did not have them too.
And thanks for the great DNS service, I'm using it everywhere!
reply