4 ms·

Well, it's not so uncommon. For instance, OpenBSD, NetBSD repos are sort of monolithic. And, believe it or not, there are some advantages. For instance, let's t

Well, it's not so uncommon. For instance, OpenBSD, NetBSD repos are sort of monolithic. And, believe it or not, there are some advantages. For instance, let's take a look at OpenBSD 5.5 [0] release notes: > OpenBSD is year 2038 ready and will run well > beyond Tue Jan 19 03:14:07 2038 UTC OpenBSD 5.5 was released on May 1, 2014. While Linux is still "not quite there yet" y2038-wise. y2038 is a very complex issue, while it may look simple - time_t and clock_t should be 64-bit. This requires changes both on the kernel -- new sys-calls interfaces [stat()], new structures layouts [struct stat], new sizeof()-s, etc. -- and the user space sides. This, basically, means ABI breakage: newer kernels will not be able to run older user space binaries. So how did OpenBSD handle that? The reason why y2038 problem looked so simple to OpenBSD was a "monolithic repository". It's a self-contained system, with the kernel and user space built together out of a single repository. OpenBSD folks changed both user space and kernel space in "one shot". IOW, a monolithic repository makes some things easier: a) make a dramatic change to A b) rebuild the world c) see what's broken, patch it d) while there are regressions or build breakages, goto (b) e) commit everything [0] http://www.openbsd.org/55.html?hn http://www.openbsd.org/55.html?hn [UPDATE: fixed spelling errors... umm, some of them] -ss

glandium 8y ago
The reason why y2038 problem looked so simple to OpenBSD has little to do with "monolithic repository" and everything to do with "happy to break kernel ABI compatibility". You're saying as much yourself. Monolithic repository might have been a tool that helped enforce it, but that's not what made it happen. It's the decision that ABI could be broken that did. And that's also why it hasn't happened in Linux yet. Even if there was a monorepo containing all the open source and free software in the world (or at least, say, that you can find in common distros), the fact that there's a contract to never break the ABI makes it simply hard to do.
- dguest 8y ago
  This is a very good point. I work in an organization that just switched to monolithic and it's been going very well, with hundreds of active developers and millions of lines of code. But our developers are students or academics. As many as half don't understand the concept of an ABI. So the monorepo works quite well for us because rebuilding from scratch is something we do multiple times a day.
- senozhatsky 8y ago
  > Monolithic repository might have been a tool that helped enforce it, > but that's not what made it happen. It's the decision that ABI could > be broken that did. Well, there are probably some subtle details which I'm missing, and may be you are totally right. The way it looks to me is as follows: They are "happy to break kernel ABI compatibility" because the repository is monolithic - they break ABI, they immediately fix user space apps. E.g. NetBSD time_t 64-bit commit: https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 They patched the kernel: sys/kern : kern_clock.c kern_descrip.c kern_event.c kern_exit.c kern_resource.c kern_subr.c kern_synch.c kern_time.c sys_generic.c syscalls.conf syscalls.master vfs_getcwd.c vfs_syscalls.c vfs_vops.c and fixed broken user space at the same time: ... sys/msdosfs : msdosfs_vnops.c sys/netinet6 : in6.c nd6.c sys/nfs : nfs_serv.c nfs_subs.c nfs_vnops.c xdr_subs.h sys/ntfs : ntfs_vnops.c sys/sys : _time.h _types.h dirent.h event.h resource.h shm.h siginfo.h stat.h sysctl.h time.h types.h vnode.h sys/ufs/ext2fs : ext2fs_lookup.c sys/ufs/ufs : ufs_vnops.c ... There is no "transitional" stage, when the kernel is already patched, but no user space apps are ready for those changes yet. It all happens at once. -ss
  - flukus 8y ago
    > There is no "transitional" stage, when the kernel is already patched, but no user space apps are ready for those changes yet. It all happens at once. What about third party apps? It's not a fully self contained system, there are binaries out there running on openBSD that the openBSD devs have never heard of, and they were broken by the change.
    - senozhatsky 8y ago
      Good point. The way BSD people look at this issue - 3rd party apps are sort of out of consideration. I think they actually consider it to be self-contained. [UPD] But I haven't checked how NetBSD handled y2038. It might be that they didn't break the ABI. In some parts, I think, OpenBSD/FreeBSD/NetBSD just converted time_t to an unsigned 32-bit int. -ss
perlgeek 8y ago
... and all the third-party software that was compiled for older versions of OpenBSD is now also broken by default. The problem is that this approach only works if it is really a self-contained system. But OpenBSD isn't: it's a basis to run software, potentially third-party software. It's can't be a closed Universe and still be useful at the same time.

glandium 8y ago

The reason why y2038 problem looked so simple to OpenBSD has little to do with "monolithic repository" and everything to do with "happy to break kernel ABI compatibility". You're saying as much yourself. Monolithic repository might have been a tool that helped enforce it, but that's not what made it happen. It's the decision that ABI could be broken that did. And that's also why it hasn't happened in Linux yet. Even if there was a monorepo containing all the open source and free software in the world (or at least, say, that you can find in common distros), the fact that there's a contract to never break the ABI makes it simply hard to do.

dguest 8y ago
This is a very good point. I work in an organization that just switched to monolithic and it's been going very well, with hundreds of active developers and millions of lines of code. But our developers are students or academics. As many as half don't understand the concept of an ABI. So the monorepo works quite well for us because rebuilding from scratch is something we do multiple times a day.
senozhatsky 8y ago
> Monolithic repository might have been a tool that helped enforce it, > but that's not what made it happen. It's the decision that ABI could > be broken that did. Well, there are probably some subtle details which I'm missing, and may be you are totally right. The way it looks to me is as follows: They are "happy to break kernel ABI compatibility" because the repository is monolithic - they break ABI, they immediately fix user space apps. E.g. NetBSD time_t 64-bit commit: https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 They patched the kernel: sys/kern : kern_clock.c kern_descrip.c kern_event.c kern_exit.c kern_resource.c kern_subr.c kern_synch.c kern_time.c sys_generic.c syscalls.conf syscalls.master vfs_getcwd.c vfs_syscalls.c vfs_vops.c and fixed broken user space at the same time: ... sys/msdosfs : msdosfs_vnops.c sys/netinet6 : in6.c nd6.c sys/nfs : nfs_serv.c nfs_subs.c nfs_vnops.c xdr_subs.h sys/ntfs : ntfs_vnops.c sys/sys : _time.h _types.h dirent.h event.h resource.h shm.h siginfo.h stat.h sysctl.h time.h types.h vnode.h sys/ufs/ext2fs : ext2fs_lookup.c sys/ufs/ufs : ufs_vnops.c ... There is no "transitional" stage, when the kernel is already patched, but no user space apps are ready for those changes yet. It all happens at once. -ss
- flukus 8y ago
  > There is no "transitional" stage, when the kernel is already patched, but no user space apps are ready for those changes yet. It all happens at once. What about third party apps? It's not a fully self contained system, there are binaries out there running on openBSD that the openBSD devs have never heard of, and they were broken by the change.
  - senozhatsky 8y ago
    Good point. The way BSD people look at this issue - 3rd party apps are sort of out of consideration. I think they actually consider it to be self-contained. [UPD] But I haven't checked how NetBSD handled y2038. It might be that they didn't break the ABI. In some parts, I think, OpenBSD/FreeBSD/NetBSD just converted time_t to an unsigned 32-bit int. -ss

perlgeek 8y ago

... and all the third-party software that was compiled for older versions of OpenBSD is now also broken by default. The problem is that this approach only works if it is really a self-contained system. But OpenBSD isn't: it's a basis to run software, potentially third-party software. It's can't be a closed Universe and still be useful at the same time.