5 ms·

> 3 years uninterupted uptime and counting. Didn't you had to install updates and patches during the past three years? Or were those sacrificed to keep an upti

by rualca 5y ago

> 3 years uninterupted uptime and counting. Didn't you had to install updates and patches during the past three years? Or were those sacrificed to keep an uptime streak that matters nothing?

Spivak 5y ago
People still take outages for patching? I think the parent means service uptime.
- rualca 5y ago
  Taking a node down does not mean outage at all. Service uptime also reads like a non-sequitur given the comment on the JDK11 crashes sounded like OP was doing something weird with the new JDKs, not with the old prod system running JDK8. JDK11 was released way back in 2018. Any claim that it's unstable these days is not credible.
DarkmSparks 5y ago
Sure, but no other updates or patches require massive rewrites to work as well as it does now, and they can be applied one machine at a time. e.g. a non insignificant portion relies on corba/rmi. it works, and works fine. switching, e.g. https://stackoverflow.com/questions/51710274/is-there-a-replacement-library-for-corba-in-jdk-11 https://stackoverflow.com/questions/51710274/is-there-a-repl... might break in unexpected ways, bringing down everything that needs it. I see 17 is potentially ripping out security manager, why? wth? So suddenly jars that expect to throw an exception if 3pd code wants to do something they arent allowed to will now just run fine? Really really very sad face.
- derefr 5y ago
  > I see 17 is potentially ripping out security manager, why? wth? Because Security Manager — which enforces runtime access capabilities, like an OS kernel does — exists for the sake of Java applets, and Java applets have been dead for a long time. The Security Manager enables secure execution of "mobile" (i.e. untrusted, not-auditable-at-time-of-release) code — cases where the "host" and "guest" codebases are compiled separately with the "host" having no ability to introspect the "guest" during the "host's" compilation, because the "guest" doesn't exist yet. Security Manager does not exist for the sake of fighting against your own project's dependencies. There are much simpler and more runtime-efficient solutions (like linters / static-analysis tools) for the case where the "host" can see the "guest's" code at compile time. Security Manager doesn't exist for the sake of "plugins" (e.g. WARs, Java Agents, etc), either. Even if you don't have a plugin's source code available in your project worktree at build time, you can still validate the plugin's behavior at release time by statically analyzing its bytecode before building it into your release fatJar. Which still allows you to make much stronger guarantees than Security Manager can.
  - DarkmSparks 5y ago
    no, not just applets. its used for any kind of secure system where developers and their components are forbidden from say network access, e.g. some nashorn map reduce javascript. java _used_ to be the language of choice for building complex systems with large multinational multidisciplinary teams. security manager was a vital part to those projects, removing security manager means none of that can migrate. why do it?
    - derefr 5y ago
      Because the modern Enterprise-y best-practice is to not allow multiple security contexts to exist within a single monolithic OS process where the OS kernel's own "security manager" can't get to them to enforce its own policy; but rather to cleave apart your process along security-context lines into multiple processes; containerize those to isolate them from each-other; poke precise holes in those containers for well-defined RPC channels to flow; and connect those channels using a service mesh with secure application-layer firewalling. No modern ops staff would trust the JVM to not be exploitable if you're exposing it as an attack surface to arbitrary user-supplied (or "third party dev who is incentivized to make a network call you don't want them to make") bytecode. Creating that kind of boundary is what technologies like gVisor and Istio are for; it's not the job of a programming-language runtime. (See also: the decline and fall of Google App Engine's "secure runtime" standard environment, in favor of the gVisor-based flexible environment.) (Well, okay, Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case, or Redis scripting for the Lua case. But this is because Node and Lua both have "shared-nothing" runtime execution semantics with no concept of static-bound identifiers [i.e. constants] — meaning that all the fundamental "stuff" available in a Node or Lua execution context is put there dynamically, and so a sandbox can be constructed "from scratch" with arbitrary stuff [mocks/stubs/proxies] inserted in place of the fundamental module handles, to create a whitelisted environment. The JVM is not built like this; the JVM's Security Manager merely blacklists certain known-dangerous operations, and so does nothing to prevent exploitation of zero-day vulnerabilities.)
      - 5y ago
- krzyk 5y ago
  > I see 17 is potentially ripping out security manager, why? wth? Because it is not used by any modern (post Java 6 probably) feature in Java? So why keep such thing? If libraries want to use such features they can create their own.

by rualca 5y ago

> 3 years uninterupted uptime and counting. Didn't you had to install updates and patches during the past three years? Or were those sacrificed to keep an uptime streak that matters nothing?

Spivak 5y ago

People still take outages for patching? I think the parent means service uptime.

rualca 5y ago
Taking a node down does not mean outage at all. Service uptime also reads like a non-sequitur given the comment on the JDK11 crashes sounded like OP was doing something weird with the new JDKs, not with the old prod system running JDK8. JDK11 was released way back in 2018. Any claim that it's unstable these days is not credible.

DarkmSparks 5y ago

Sure, but no other updates or patches require massive rewrites to work as well as it does now, and they can be applied one machine at a time. e.g. a non insignificant portion relies on corba/rmi. it works, and works fine. switching, e.g. https://stackoverflow.com/questions/51710274/is-there-a-replacement-library-for-corba-in-jdk-11 https://stackoverflow.com/questions/51710274/is-there-a-repl... might break in unexpected ways, bringing down everything that needs it. I see 17 is potentially ripping out security manager, why? wth? So suddenly jars that expect to throw an exception if 3pd code wants to do something they arent allowed to will now just run fine? Really really very sad face.

derefr 5y ago
> I see 17 is potentially ripping out security manager, why? wth? Because Security Manager — which enforces runtime access capabilities, like an OS kernel does — exists for the sake of Java applets, and Java applets have been dead for a long time. The Security Manager enables secure execution of "mobile" (i.e. untrusted, not-auditable-at-time-of-release) code — cases where the "host" and "guest" codebases are compiled separately with the "host" having no ability to introspect the "guest" during the "host's" compilation, because the "guest" doesn't exist yet. Security Manager does not exist for the sake of fighting against your own project's dependencies. There are much simpler and more runtime-efficient solutions (like linters / static-analysis tools) for the case where the "host" can see the "guest's" code at compile time. Security Manager doesn't exist for the sake of "plugins" (e.g. WARs, Java Agents, etc), either. Even if you don't have a plugin's source code available in your project worktree at build time, you can still validate the plugin's behavior at release time by statically analyzing its bytecode before building it into your release fatJar. Which still allows you to make much stronger guarantees than Security Manager can.
- DarkmSparks 5y ago
  no, not just applets. its used for any kind of secure system where developers and their components are forbidden from say network access, e.g. some nashorn map reduce javascript. java _used_ to be the language of choice for building complex systems with large multinational multidisciplinary teams. security manager was a vital part to those projects, removing security manager means none of that can migrate. why do it?
  - derefr 5y ago
    Because the modern Enterprise-y best-practice is to not allow multiple security contexts to exist within a single monolithic OS process where the OS kernel's own "security manager" can't get to them to enforce its own policy; but rather to cleave apart your process along security-context lines into multiple processes; containerize those to isolate them from each-other; poke precise holes in those containers for well-defined RPC channels to flow; and connect those channels using a service mesh with secure application-layer firewalling. No modern ops staff would trust the JVM to not be exploitable if you're exposing it as an attack surface to arbitrary user-supplied (or "third party dev who is incentivized to make a network call you don't want them to make") bytecode. Creating that kind of boundary is what technologies like gVisor and Istio are for; it's not the job of a programming-language runtime. (See also: the decline and fall of Google App Engine's "secure runtime" standard environment, in favor of the gVisor-based flexible environment.) (Well, okay, Node and Lua are both runtimes that have trustworthy VM-level isolation that can be used to achieve this — see Cloudflare Workers for the Node case, or Redis scripting for the Lua case. But this is because Node and Lua both have "shared-nothing" runtime execution semantics with no concept of static-bound identifiers [i.e. constants] — meaning that all the fundamental "stuff" available in a Node or Lua execution context is put there dynamically, and so a sandbox can be constructed "from scratch" with arbitrary stuff [mocks/stubs/proxies] inserted in place of the fundamental module handles, to create a whitelisted environment. The JVM is not built like this; the JVM's Security Manager merely blacklists certain known-dangerous operations, and so does nothing to prevent exploitation of zero-day vulnerabilities.)
    - 5y ago
krzyk 5y ago
> I see 17 is potentially ripping out security manager, why? wth? Because it is not used by any modern (post Java 6 probably) feature in Java? So why keep such thing? If libraries want to use such features they can create their own.