Posts by simpfeld 170 publicly visible posts • joined 24 Sep 2009
The big issues always were, this was the next big thing in the '80s for a while.
Optical wavelengths are just too big for today's circuits, so not very high density.
Hence today's chip layouts can't be seen by an optical microscope any lithography no longer uses visible wavelengths.
A bigger issue is heat. An electronic transistor when off no current flows.
An optical transistor when off essentially goes black, so just generates heat.
That's a big problem with upping density.
Are we in the territory of two bald men fighting over a comb?
Not saying it's not good, just that Ruby doesn't need more roadblocks.
It's like the other great Ruby project puppet, being closed further by it's owner Perforce, it was fighting for it's existence before....what are the thinking?
All true, however there are a very large number of sites that don't use these VMWare features, they just bought VMWare as it was the safe, nobody got fired for buying VMWare, option.
Not sure RHEV/oVirt skill are so problematic as they are all KVM and this is a pretty common skill, any half decent Linux admin can work with this. If I was a VMWare admin I would be learning those right now.
Bigger sites, I'd be looking at Nutanix and cloud, as in the next few years you will be in milking territory for Broadcom.
Other things to consider.
If you can take the price rises great, but remember, Broadcom has cut off a lot of resources from home labs/self learners.
This will start to make staff availability harder as the years drift by.
VMWare is on the path to be a legacy technology, it will be like mainframe technology. Still super reliable but no one is interested in this.
Also you do have to ask yourself how many 3rd party software and maybe more importantly Hardware vendors will be interested in supporting
this if market share starts to disappear. Could we see a day with Broadcom's own hardware being required because of it being too hard for them to support
from every server vendor? This isn't Linux they have to maintain their own kernel.
These aren't going to be a problem now, but looking out 5-10 years ? Not so long in enterprise terms.
This was a dynamic ecosystem, it isn't now.
All I'd say, just keep your eyes open and look beyond today's value provided to ensure you don't get technologically marooned.
I think this looks more like a display driver issue or something else going on.
I've being playing DVD ISOs since the Pi3 era and Pi4 was happy doing full 1080 blu-ray ISOs.
I'm happily running H265 4K video files on my Pi5.All with plenty of CPU headroom left.
I'm likewise using a LibreELEC Kodi to be TV friendly but should still be capable on a RaspberryPi OS.
Reducing your exposure to the windows pathogen seems the correct approach. I have a Linux host with 95% of the apps I use , and a Widows VM for the few apps I can't get.
Continuing to fight to keep windows just opens you up to being data harvested to death (forced MS accounts) and now forced HW upgrades.
I'd wonder more about the impact of these changes on the technology.
Will the products on each side be impacted by being disconnected from advancements in the other.
Even if they have an intellectual property sharing deal, having say, desktop as no longer being part of VMWare will mean no (a lot less) consideration to this being paid by VMWare to this when making changes.
Couldn't agree more!
I have been a Red Hat user, supporter and customer of Red Hat Linux (not RHEL) from about 5.x.
As a customer of RH I benefited from the large install base Centos brought, vendors providing their software in RPM, but mainly the benefits were third party repos and FAQs/howtos made largely by Centos/Alma/Rocky people.
I too have migrated my home servers all to Debian from Rocky, a bit of a pain but I got there.
I used to provide bug reports for Centos (checked on RHEL) for things I spotted at home, to make RHEL better.
But more importantly I provided early testing of Fedora in corporate environments (plus at home), in the hope that when the RHEL release came it would be more bug free in a corporate setting. I also would benefit at home by these improvements trickling down to Centos/Alma/Rocky.
Now why should I help Fedora to just be largely called a thief by Red Hat. Thanks for that...Not a nice thing to call your customers who often used Centos for prototyping before buying the real thing under RHEL. My desktops and laptops switched to an Ubuntu spin.
Red Hat you largely had a nice symbiotic relationship going with Fedora and downstream Centos. I believe a massive own goal! Short term gain at the price of the long term.
This has been resisted for so long, and was so obviously needed.
I have .lan at home mainly as OpenWRT uses this and it's quicker to type than .internal.
To be honest I'd reserve common ones used (identified in the report) and not just one, then just move on.
i.e. .home, .internal, .lan, .corp, .localdomain
I can see it actually being more sensible for an AD domain to be companyname.{corp|lan|internal} than a real (as recommended by MS).
Companies often forget to renew real domains (then your are stuck).
I hear you, but most broadband issues do still seem to be Openreach.
All the issues I have had in different places are Openreach. A dodgy shotgun style cable being left by Openreach when it should have been replaced when we had broadband installed. A bad connection in the cabinet,tech showed us a bad plastic covered join.
A horribly congested link from the Exchange (we were told, where Zen had no direct presence in that Exchange), it would be great during the day (65Mbs) but would drop top 0.1 Mbs in the evening even though the syncing speed was still very high.
And of course they have the hardest job to provide broadband on an ancient physical infrastructure.
I used to test Fedora on my company's enterprise environment (AD, NFSv4, WiFi etc) and home desktop, and reported issues back to Red Hat in the hope of getting these fixed before they became issues on new RHEL releases. I was a large RHEL customer. I used to benefit personally by having CentOS/Rocky at home. Nice symbiotic relationship.
Now with being called a freeloader and worries about the viability of essential 3rd Party Repos on RHEL, I see no reason to help RH improve their distro, given they are freeloading off my efforts!
Home is now Debian 12 Servers and Ubuntu based.
Maybe someone can help me with this...
What direction/philosophy are they taking with this?
Is this going to be an effective new distro tree that is developed independently (that the members will derive from)?
OR
An effective new distro tree that is using Centos Stream patches (that the members will derive from)?
OR
Just a new name for the upstream RHEL sources?
Personally after using RH and RHEL for decades professionally (and recommending to many people and the companies I've worked for), and using Fedora and Centos/Rocky at home. Contributing bug reports and enterprise experience of their product back. This was only practical at work and home by use of 3rd party repos to make this practical, largely maintained by Alma/Rocky/Centos people. For us all to be called leeches, thanks for that.
I'm now done with them and have already moved my home stuff to Debian and work will likely follow!
I wonder if just a directive from their corporate Daddy to increase profits after they splurged on buying Red Hat. This will likely come back to bite them, but those C levels will have had their bonuses by then and moved on. RH themselves used to say if we make money from bits we aren't doing it properly....
Sadly I think you are right.
I have used RHEL commercially and recommended buying it (and have run a very large RHEL subscription account). Wanted to run the same thing at home (so used Centos later Rocky).
As a RHEL subscriber benefited many times from the many eyes of Centos (howtos, bug reports, forum posts) and the repos with essential third party software built with Centos (e.g. certbot, vlc, nvidia driver rpms, ). The extra audience provided by Centos gave me more 3rd party software availability. Additionally, just a few weeks ago I had a bug I found in Rocky ( I tested on RHEL to report), pushed upstream and has been fixed.
Without all this RHEL just became a whole lot less useful and usable. If you run a single commercial app maybe not, but in the real world RHEL just now looks hard to use as a general purpose distro.
I have used RHEL systems for many many years (decades) and contributed to this ecosystem (many many bug reports, howtos, occasional patches)
And to Fedora, I run this as a desktop (home and work) to see what was coming up in RHEL a few years down the line and to help stabilise it for this point. So my RHEL and my home Rocky deployments would be improved.
Why would I do this now? I just don't feel like doing this anymore. If my home servers head to something else my desktop will too.
RH you have utterly destroyed the ecosystem you have built. On some short term hope of gain.
At the weekend I downloaded Debian for the first time in decades and I have started playing with this in a VM. I have decided what desktop system I may use, maybe Debian maybe something else Debian based.
It's all very sad.
BTRFS seems to have had issues with things like RAID 5/6 forever, but not really something I know about the reasons on priorities of BTRFS.
The Bcachefs patreon page has some discussion. Not sure on the validity (or the other side of the argument) but it's interesting:
https://www.patreon.com/bcachefs
ext4 - which works - mostly - but is showing its age. The codebase terrifies most filesystem developers who have had to work on it, and heavy users still run into terrifying performance and data corruption bugs with frightening regularity. The general opinion of filesystem developers is that it's a miracle it works as well as it does, and ext4's best feature is its fsck (which does indeed work miracles).
xfs - which is reliable and robust but still fundamentally a classical design - it's designed around update in place, not copy on write (COW). As someone who's both read and written quite a bit of filesystem code, the xfs developers (and Dave Chinner in particular) routinely impress me with just how rigorous their code is - the quality of the xfs code is genuinely head and shoulders above any other upstream filesystem. Unfortunately, there is a long list of very desirable features that are not really possible in a non COW filesystem, and it is generally recognized that xfs will not be the vehicle for those features.
btrfs - which was supposed to be Linux's next generation COW filesystem - Linux's answer to zfs. Unfortunately, too much code was written too quickly without focusing on getting the core design correct first, and now it has too many design mistakes baked into the on disk format and an enormous, messy codebase - bigger that xfs. It's taken far too long to stabilize as well - poisoning the well for future
I do hope this gets merged soon, it looks like a decent Next Generation filesystem architecture that might replace the muddle we have at the moment without ZFS licensing issues or BTRFS (alleged) architecture issues. And has data integrity checking without the layering nightmare of stratis.
They never seem to get that the reason I called is that the website didn't allow me to do the more complex thing I'm trying to do.
As an example, I have a locked out account just now with MS and I can't get a number anywhere to talk to a human being, the automatic reset doesn't want to play with this account. Stuck at the moment!
To be honest following the link to Fedora on this they say removing NIS(+). So presumably/possibly the biggest issue was removing NIS support, as opposed to NIS+ support.
NIS+ being nothing like NIS at all.
I can imagine a number of sites might still use NIS, was used a lot in HPC. Can't imagine NIS+ is used now by anyone, no one really used it when it launched. Sun Solaris originally only provided a NIS+ server, but so few people used it later versions came with a NIS server too.
When you look at most Google Open Source projects, there is no real community directed activity.
It's just Google chucks it over the wall.
Android is like this
Another example. Chromium has no ability to sync passwords, bookmarks, passwords etc to anything that isn't Google's cloud.
Bugs for this are just closed for Chromium,
But only to share Windows files out for Linux desktop users. So light usage. It was okay for this (maybe very okay), but the lack of reasonably handling of filename case issue would prevent me from doing anything deeper with it.
One thing was there is no group ownership file that you can set in the GUI even though this is stored in NTFS and used by their NFS. I had to write my own chgrp in PowerShell :(
Would have been easier if they had just exposed the NFSv4 ACL's mapped from NTFS ACL's (they are pretty identical), but they only map ACL entries for owner, group and other (everyone on NTFS) to basic unix perms. Hence the need for a chgrp.
There have been fundamental problems with photonic computing for a long time.
One is heat dissipation, when an optical gate is off it effectively goes black so just generates heat. Transistors don't do this.
Secondly, light is quite large. Chips are already have feature massively smaller than optical wavelength, lithography requiring ultraviolet light these days. So any optical chip will have to be larger (features wise) than an equivalent electronic chip.
So basically for bulk across board/CPU maybe high bandwidth comms is the likely immediate and perhaps only possible use for photonics in the immediate future.
Surface plasmons are probably a more likely path for actual computation.
One other thing is that optical fibres have a pretty slow propagation rate has a VF (Velocity Factor) of about 0.6-0.7 (of the speed of light in a vacuum), decent coax can do 0.8-0.9. This higher bandwidth of fibre usually makes this much more preferable but for certain in computer functions this maybe a limiting factor (memory buses perhaps). I just mention this as hardly anyone seems to know this.
I see why they aren't doing QUIC/IP or QIC/IP as current routers wouldn't implement it, but this effectively renders the IP protocol number useless.
A new protocol layered over UDP (as we have layered a load of crap on port 443) just more layering inefficiency.
Could this not have been a full IP protocol with drop back to UDP if this wasn't available?
To be honest you can do really smart on IPv6 with Prefix Translation, because you have so many external addresses you can have 1-to-1 mapping of external to internal addresses, it should work great. Much better than IPv4 port hackery.
Sadly there is a big BUT coming, the private addresses you can assign officially in IPv6 ULAs (fd00::/8) will NEVER be used for Internet traffic (I believe usually hard coded into the stacks and will drop back to IPv4 if you try, so I have read (not tried it)). So your choice is to use an unused piece of the real address space, it's unused this week, so this may well come back to bite you.
Sadly the Ivory Tower people that architect these sort of things have made NAT IPv6 hard to do well.
A bit analogous to the Ivory Tower people that don't want to give out a decent set of private top-level domain names for internal use....
I have to agree. Very ho-hum. Given how rarely IPv4 addresses change (and you want this) and a fixed IPv4 address is common, I don't really see this is massively worse. Also my IoT devices (hopefully) talk to their single AWS cloud services, so not really leaking to lots of Internet sites, a TV a little more but still a very limited pool of sites. Phones and things that actually leave my house are all random assignment.
Besides I have a fixed PD delegation anyway, knowing my end device isn't a big further hole.
To be honest, I'd personally love to us pure DHCPv6 and not SLAAC at home, but Android doesn't support it! Due to a super awkward Android developers with an obsession that we should all use SLAAC and nothing else...
https://issuetracker.google.com/issues/36949085?pli=1
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
