10 ms·

FreeBSD 4 Bug may be present in Playstation 4/5

143 points by gotschi_ 3y ago

tiffanyh 3y ago
FreeBSD 4.x was considered by many as the most stable FreeBSD ever. Mainly because there were 11 point releases of fixes and enhancements (4.11), as opposed to today where FreeBSD major version only have 3-4 point releases. https://www.freebsd.org/releases/ https://www.freebsd.org/releases/
- datadeft 3y ago
  Wasn't this the last version before Matthew Dillon forked the project? I remember seeing some public arguments about SMP and few details of the kernel that resulted in fork and the new version 5.x.
  - throwaway71271 3y ago
    yea: https://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html https://lists.freebsd.org/pipermail/freebsd-current/2003-Jul...
    - tiffanyh 3y ago
      DragonflyBSD is typically on-par or slightly faster than Ubuntu (Linux) or FreeBSD. And that's with a radically smaller # of developers working on it. https://www.phoronix.com/review/corei9-freebsd13-dfly6/4 https://www.phoronix.com/review/corei9-freebsd13-dfly6/4 -- Yes, I know the common complaint is benchmarks are flawed and how Phoronix could do more meaningful test. But the reality is, nearly no one even does comprehensive OS benchmarking anymore - so there isn't really a good alternative source to use.
      - znpy 3y ago
        > But the reality is, nearly no one even does comprehensive OS benchmarking anymore - so there isn't really a good alternative source to use. Imho benchmarks only get you so far. If yu are any kind of serious about performance you should do your own testing and benchmarking. Benchmarks from other people should only help you selecting candidates platforms on which to run your own benchmarks.
      - throwaway71271 3y ago
        In the very beginning I think they(df) used pgbench kind of benchmarks 'the smp' benchmark, as a lot of people were using postgres and was really easy to compare qps and transactions per second, of course it also tests ufs2 vs hammer. (if I remember correctly) It was a long time ago, but freebsd5 felt more like a new OS than just a 4.11->5.0 bump, particularly with the removal of the giant lock and all the witness(4) work, took a while to figure out how to finetune it as a lot of systems were giant free but not all, and also of course moving one lock to many small locks means a lot of spinning and certain patterns of workloads are slower than before. It took until 7.0 to get amazing, and then in 8 or so I think it was super solid. Dragonfly went with kernel messaging and one scheduler per core, and FreeBSD spent a lot of time into making a preemptive scheduler (sched_ule (4) : http://fxr.watson.org/fxr/source/kern/sched_ule.c?v=FREEBSD-5-STABLE http://fxr.watson.org/fxr/source/kern/sched_ule.c?v=FREEBSD-...) Weird times, but I am super grateful that both the FreeBSD team and the DragonflyBSD team did what they think is right. Mad respect to the people who are just coding what they think is right.
- throw0101d 3y ago
  > Mainly because there were 11 point releases of fixes and enhancements (4.11), as opposed to today where FreeBSD major version only have 3-4 point releases. Mostly because 5.x took so long to be released. IIRC, shortly after this experience the FreeBSD folks went from a feature-based release cycle to a time-based release cycle: everyone wanted feature X (and X and Y) in Next Release, and things got pushed and pushed. So by having a steady cadence, a feature could be integrated regularly into HEAD, and folks didn't have to wait too long before a STABLE release was cut with all the latest and greatest stuff (that couldn't otherwise be backported because of compatibility guarantees).
  - sgift 3y ago
    Same experience which lead Java to change from feature-based release cycle to time-based release cycle later. Make regular releases, everything that is ready gets included, everything else can go onto the next train. Far better.
- zare_st 3y ago
  Yeah a lot has changed since then. We had to keep track of stable branch to get close to Linux desktop features most of the time, sometimes even 'current' branch. Today you can use release for 99.9% of use cases, and upgrading releases minor or major is pretty straightforward and way faster than it used to be.
- adrian_b 3y ago
  It was not only the most stable, but for many applications, especially in networking, it was also the fastest single-threaded operating system, beating easily Linux and Windows XP or 2000. Unfortunately for FreeBSD, the launch of the Intel Pentium 4 with hyper-threading in 2003, then of the AMD dual-core CPUs in 2005 have made quickly FreeBSD 4 completely obsolete. The smaller FreeBSD team has required many years until achieving a decent implementation for multi-threaded CPUs and during that time they have remained long behind Linux and other operating systems. Besides perfect stability (it was normal to not reboot FreeBSD 4 for years) and great networking performance, it also had a much more reliable file system than the competition. Despite the fact that Windows XP used NTFS and Linux had at least 3 file systems with journaling at that time, where journaling was supposed to make the file systems crash-resistant, I have seen at that time (around 1999-2003) many cases of file system corruptions after power outages, on computers without UPSes which used NTFS or Linux file systems with journaling (on Linux EXT2 without journaling any power outage was very likely to require a complete reinstallation). During the same power outages, the computers with FreeBSD that used the UFS file system with "soft updates" never experienced any file system corruption, despite the fact that UFS with "soft updates" was not a journaling file system, but only one where the disk write operations were carefully ordered in such a way as to prevent unrecoverable file system corruption in the case of a crash.
  - hn8305823 3y ago
    I've only ever lost data on Linux ext* filesystems, never on FreeBSD UFS or ZFS. 20 years ago it was unfortunately not unusual to experience the Linux "nuclear fsck" where it scrolls by so fast and for so long you know it's toast.
    - SomeoneFromCA 3y ago
      Hell no. I worked in an ISP in late 90s. NTFS was absolutely rock reliable, then (much worse)ext2, then (slightly worse) UFS, and then FAT.
      - yjftsjthsd-h 3y ago
- nachteilig 3y ago
  I loved FreeBSD 4. Stable and the first I really deployed wisely. Still have good memories of building world!
- makeitdouble 3y ago
  That's also the period Yahoo and other companies had a tremendous investment in FreeBSD. FreeBSD is great on its own, and that amount of attention also meant every single bit of performance would be extracted no matter what it takes, and any scaling or stability issues would be hammered out pretty quick. Until they moved to redhat...
  - znpy 3y ago
    > Until they moved to redhat... Does anybody know why they switched to RedHat ?
    - makeitdouble 3y ago
      I always assumed money, but I'd love to know as well.
    - tiffanyh 3y ago
      This old thread has former Y! folks chiming in as to why. https://news.ycombinator.com/item?id=10558288 https://news.ycombinator.com/item?id=10558288 > I think the justifications were better support for running on Linux (storage drivers, Java, MySQL, oracle), better support for virtualization (although bsd jails are better than virtualization in my opinion, and a better fit for Y!), and it would be easier to support one os instead of two and acquisitions (including inktomi) really wanted to run on Linux.
      - znpy 3y ago
        Interesting, from that links i see some replies like this: > Also, the FreeBSD license was more relaxed and commercial products (like NetAPP) could include and extend FreeBSD without disclosing their modifications. and then (same comment): > Our frustration with lack of support for FreeBSD moved us to choose Linux and Windows I think these two things are strongly correlated: the bsd license allow companies to avoid contributing back improvements, and this prevents the main FreeBSD codebase from getting better. I think that in the long run this is detrimental to projects.
- loeg 3y ago
  Likely also by comparison to FreeBSD 5 directly after it, which introduced concurrent kernel entry (instead of a single giant lock) and was considered somewhat buggy for a while. Or so I am told.
  - 0x457 3y ago
    5.x was extremely buggy and unstable. It got usable around only after 5.4 release. 5.x wasn't just the removal of Giant Lock, but also: - GEOM - Kernel Scheduled Entities There weren't any reasons to switch from 4.x to 5.x until 5.x got stable. Even with Giant Lock given the hardware at the time (Pentium with hyper threading) it wasn't that bad.
- vehemenz 3y ago
  I never looked into the release history, but I ran a server with 4.10 for 8 or 9 years and never felt the need to upgrade it.
WhereIsTheTruth 3y ago
Time to buy a PS5 before this gets patched!
- speps 3y ago
  It's already patched: > Early tests seem to indicate that a crash is indeed present in PS4 up to 11.00 included, and PS5 8.20 included. (Which would put the patch for this issue at firmwares PS5 8.40 and PS4 11.02)
  - WhereIsTheTruth 3y ago
    Not the ones sitting in the store
  - MuffinFlavored 3y ago
    I wonder if that's how the "hacker community" knew to look for it, doing a diff of what gets "flashed" 8.20 -> 8.40?
    - bdhcuidbebe 3y ago
      its because someone cashed out 50k dollars from sony for a undisclosed kex recently. https://hackerone.com/aapo?type=user https://hackerone.com/aapo?type=user
hulitu 3y ago
OT. Can we ban "may" and "could" from submission titles ? It will greatly increase the quality of articles on HN.
- deleted 3y ago
  [deleted]
- bdhcuidbebe 3y ago
  ps5 was jailbroken recently so theres some merit to this claim wololo has been reporting in it, and mvg made a video about current state of things https://youtu.be/5Cq3K9lBli0 https://youtu.be/5Cq3K9lBli0
- zogrodea 3y ago
  I read the article and found it interesting to be honest (and enjoyed reading people's comments here on their experience with FreeBSD), although it is a rumour and I agree there are good reasons for disallowing/filtering those.

143 points by gotschi_ 3y ago

FreeBSD 4.x was considered by many as the most stable FreeBSD ever. Mainly because there were 11 point releases of fixes and enhancements (4.11), as opposed to today where FreeBSD major version only have 3-4 point releases. https://www.freebsd.org/releases/ https://www.freebsd.org/releases/

datadeft 3y ago
Wasn't this the last version before Matthew Dillon forked the project? I remember seeing some public arguments about SMP and few details of the kernel that resulted in fork and the new version 5.x.
- throwaway71271 3y ago
  yea: https://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html https://lists.freebsd.org/pipermail/freebsd-current/2003-Jul...
  - tiffanyh 3y ago
    DragonflyBSD is typically on-par or slightly faster than Ubuntu (Linux) or FreeBSD. And that's with a radically smaller # of developers working on it. https://www.phoronix.com/review/corei9-freebsd13-dfly6/4 https://www.phoronix.com/review/corei9-freebsd13-dfly6/4 -- Yes, I know the common complaint is benchmarks are flawed and how Phoronix could do more meaningful test. But the reality is, nearly no one even does comprehensive OS benchmarking anymore - so there isn't really a good alternative source to use.
    - znpy 3y ago
      > But the reality is, nearly no one even does comprehensive OS benchmarking anymore - so there isn't really a good alternative source to use. Imho benchmarks only get you so far. If yu are any kind of serious about performance you should do your own testing and benchmarking. Benchmarks from other people should only help you selecting candidates platforms on which to run your own benchmarks.
    - throwaway71271 3y ago
      In the very beginning I think they(df) used pgbench kind of benchmarks 'the smp' benchmark, as a lot of people were using postgres and was really easy to compare qps and transactions per second, of course it also tests ufs2 vs hammer. (if I remember correctly) It was a long time ago, but freebsd5 felt more like a new OS than just a 4.11->5.0 bump, particularly with the removal of the giant lock and all the witness(4) work, took a while to figure out how to finetune it as a lot of systems were giant free but not all, and also of course moving one lock to many small locks means a lot of spinning and certain patterns of workloads are slower than before. It took until 7.0 to get amazing, and then in 8 or so I think it was super solid. Dragonfly went with kernel messaging and one scheduler per core, and FreeBSD spent a lot of time into making a preemptive scheduler (sched_ule (4) : http://fxr.watson.org/fxr/source/kern/sched_ule.c?v=FREEBSD-5-STABLE http://fxr.watson.org/fxr/source/kern/sched_ule.c?v=FREEBSD-...) Weird times, but I am super grateful that both the FreeBSD team and the DragonflyBSD team did what they think is right. Mad respect to the people who are just coding what they think is right.
throw0101d 3y ago
> Mainly because there were 11 point releases of fixes and enhancements (4.11), as opposed to today where FreeBSD major version only have 3-4 point releases. Mostly because 5.x took so long to be released. IIRC, shortly after this experience the FreeBSD folks went from a feature-based release cycle to a time-based release cycle: everyone wanted feature X (and X and Y) in Next Release, and things got pushed and pushed. So by having a steady cadence, a feature could be integrated regularly into HEAD, and folks didn't have to wait too long before a STABLE release was cut with all the latest and greatest stuff (that couldn't otherwise be backported because of compatibility guarantees).
- sgift 3y ago
  Same experience which lead Java to change from feature-based release cycle to time-based release cycle later. Make regular releases, everything that is ready gets included, everything else can go onto the next train. Far better.
zare_st 3y ago
Yeah a lot has changed since then. We had to keep track of stable branch to get close to Linux desktop features most of the time, sometimes even 'current' branch. Today you can use release for 99.9% of use cases, and upgrading releases minor or major is pretty straightforward and way faster than it used to be.
adrian_b 3y ago
It was not only the most stable, but for many applications, especially in networking, it was also the fastest single-threaded operating system, beating easily Linux and Windows XP or 2000. Unfortunately for FreeBSD, the launch of the Intel Pentium 4 with hyper-threading in 2003, then of the AMD dual-core CPUs in 2005 have made quickly FreeBSD 4 completely obsolete. The smaller FreeBSD team has required many years until achieving a decent implementation for multi-threaded CPUs and during that time they have remained long behind Linux and other operating systems. Besides perfect stability (it was normal to not reboot FreeBSD 4 for years) and great networking performance, it also had a much more reliable file system than the competition. Despite the fact that Windows XP used NTFS and Linux had at least 3 file systems with journaling at that time, where journaling was supposed to make the file systems crash-resistant, I have seen at that time (around 1999-2003) many cases of file system corruptions after power outages, on computers without UPSes which used NTFS or Linux file systems with journaling (on Linux EXT2 without journaling any power outage was very likely to require a complete reinstallation). During the same power outages, the computers with FreeBSD that used the UFS file system with "soft updates" never experienced any file system corruption, despite the fact that UFS with "soft updates" was not a journaling file system, but only one where the disk write operations were carefully ordered in such a way as to prevent unrecoverable file system corruption in the case of a crash.
- hn8305823 3y ago
  I've only ever lost data on Linux ext* filesystems, never on FreeBSD UFS or ZFS. 20 years ago it was unfortunately not unusual to experience the Linux "nuclear fsck" where it scrolls by so fast and for so long you know it's toast.
  - SomeoneFromCA 3y ago
    Hell no. I worked in an ISP in late 90s. NTFS was absolutely rock reliable, then (much worse)ext2, then (slightly worse) UFS, and then FAT.
    - yjftsjthsd-h 3y ago
nachteilig 3y ago
I loved FreeBSD 4. Stable and the first I really deployed wisely. Still have good memories of building world!
makeitdouble 3y ago
That's also the period Yahoo and other companies had a tremendous investment in FreeBSD. FreeBSD is great on its own, and that amount of attention also meant every single bit of performance would be extracted no matter what it takes, and any scaling or stability issues would be hammered out pretty quick. Until they moved to redhat...
- znpy 3y ago
  > Until they moved to redhat... Does anybody know why they switched to RedHat ?
  - makeitdouble 3y ago
    I always assumed money, but I'd love to know as well.
  - tiffanyh 3y ago
    This old thread has former Y! folks chiming in as to why. https://news.ycombinator.com/item?id=10558288 https://news.ycombinator.com/item?id=10558288 > I think the justifications were better support for running on Linux (storage drivers, Java, MySQL, oracle), better support for virtualization (although bsd jails are better than virtualization in my opinion, and a better fit for Y!), and it would be easier to support one os instead of two and acquisitions (including inktomi) really wanted to run on Linux.
    - znpy 3y ago
      Interesting, from that links i see some replies like this: > Also, the FreeBSD license was more relaxed and commercial products (like NetAPP) could include and extend FreeBSD without disclosing their modifications. and then (same comment): > Our frustration with lack of support for FreeBSD moved us to choose Linux and Windows I think these two things are strongly correlated: the bsd license allow companies to avoid contributing back improvements, and this prevents the main FreeBSD codebase from getting better. I think that in the long run this is detrimental to projects.
loeg 3y ago
Likely also by comparison to FreeBSD 5 directly after it, which introduced concurrent kernel entry (instead of a single giant lock) and was considered somewhat buggy for a while. Or so I am told.
- 0x457 3y ago
  5.x was extremely buggy and unstable. It got usable around only after 5.4 release. 5.x wasn't just the removal of Giant Lock, but also: - GEOM - Kernel Scheduled Entities There weren't any reasons to switch from 4.x to 5.x until 5.x got stable. Even with Giant Lock given the hardware at the time (Pentium with hyper threading) it wasn't that bad.
vehemenz 3y ago
I never looked into the release history, but I ran a server with 4.10 for 8 or 9 years and never felt the need to upgrade it.

WhereIsTheTruth 3y ago

Time to buy a PS5 before this gets patched!

speps 3y ago
It's already patched: > Early tests seem to indicate that a crash is indeed present in PS4 up to 11.00 included, and PS5 8.20 included. (Which would put the patch for this issue at firmwares PS5 8.40 and PS4 11.02)
- WhereIsTheTruth 3y ago
  Not the ones sitting in the store
- MuffinFlavored 3y ago
  I wonder if that's how the "hacker community" knew to look for it, doing a diff of what gets "flashed" 8.20 -> 8.40?
  - bdhcuidbebe 3y ago
    its because someone cashed out 50k dollars from sony for a undisclosed kex recently. https://hackerone.com/aapo?type=user https://hackerone.com/aapo?type=user

hulitu 3y ago

OT. Can we ban "may" and "could" from submission titles ? It will greatly increase the quality of articles on HN.

deleted 3y ago
[deleted]
bdhcuidbebe 3y ago
ps5 was jailbroken recently so theres some merit to this claim wololo has been reporting in it, and mvg made a video about current state of things https://youtu.be/5Cq3K9lBli0 https://youtu.be/5Cq3K9lBli0
zogrodea 3y ago
I read the article and found it interesting to be honest (and enjoyed reading people's comments here on their experience with FreeBSD), although it is a rumour and I agree there are good reasons for disallowing/filtering those.