assets/developer-notes/stephanie-gawroriski/2016/01/01.mkd

   1 # 2016/01/01
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 00:47
  10
  11 Happy New Year!
  12
  13 ## 00:49
  14
  15 Currently resetting up one of my laptops. I am going to install FreeBSD on it
  16 along with Java 8 so I have an additional way to test building my operating
  17 system and such. Right now I have only really worked with Windows (which I have
  18 yet to test with the refactored code) and Linux (which I currently use and it
  19 works). I am also switching to btrfs instead of ext4 on it. Hopefully I do not
  20 have the same experience I had 4 years ago when I used it. That experience
  21 being major filesystem corruption on a bad power off.
  22
  23 ## 04:47
  24
  25 Caveats with plan. ZFS is not supported in FreeBSD for PowerPC systems and
  26 some software I used on Linux does not work with btrfs. The major thing with
  27 FreeBSD however is that I have to build everything from scratch. There is the
  28 `ports.txz` archive, however it contains all of the code just merged into
  29 an entire archive. So for example there are utilties, servers, games, and more
  30 combined all into one. So say if there is a port called _foo_, you would
  31 essentially have to extract the entire archive when you might not use all of
  32 it. For Foobarniux however, all packages can essentially be prebuilt. The
  33 sources and such are separate also. Thinking of that, it would be possible for
  34 hairball to support ZIP files containing source code. So thinking about it, I
  35 can write my own file manager which uses `PackageContents` instead of the file
  36 system. That would then mean that having the sources extracted to the disk
  37 would not be required at all. So this by itself would be very handy. The
  38 thing though is that there would essentially be a source directory and a source
  39 extraction so to speak. I could see a point where one is trying to build
  40 Foobarniux and they have extra source ZIP files perhaps for say 8-bit Z80 CPUs.
  41 Hairball would have to choose which one to install for example.
  42
  43 ## 04:54
  44
  45 On the FreeBSD system, I hope the OpenJDK in the ports is old enough because
  46 otherwise I would not be able to use JamVM due to incompatible changes made in
  47 more recent versions.
  48
  49         openjdk version "1.8.0_40-internal"
  50         OpenJDK Runtime Environment (build 1.8.0_40-internal-b04)
  51         JamVM (build 2.0.0, inline-threaded interpreter with stack-caching)
  52
  53 My release is quite old but it is supported, which is why I use it.
  54
  55 ## 05:02
  56
  57 Also using the file managers, I can completely remove the need for temporary
  58 files, even though it will use up memory rather than disk space. So for memory
  59 constrained systems (perhaps say the N64 or Dreamcast) building might be
  60 troublesome. I could also have a system property and a basic check for the
  61 amount of free memory the JVM has. The intermediary files could also even be
  62 compressed with GZip in memory.
  63
  64 ## 05:09
  65
  66 Definitely must get used to the new year, was typing out **2015/12...**.
  67
  68 ## 05:17
  69
  70 Also, a purely in memory system would be agnostic to the disk and how files are
  71 stored on it. Foobarniux might be being built on DOS or similar.
  72
  73 ## 11:59
  74
  75 The OpenJDK in ports is from March 3, 2014. This is 15 days before the first
  76 release, so it is quite old. However despite it being that old it will work
  77 because it does not change the VM stuff. Plus Foobarniux should be able to be
  78 built by any Java 8 version of the JDK.
  79
  80 ## 12:26
  81
  82 JamVM would be far superior to the very slow but precise Zero VM.
  83