Honest question: How often do people upgrade their production language?
Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading your library or framework can be more often, but I tend to still be fairly conservative. Upgrading your language for production twice a year sounds crazy to me.
In the JavaScript world people use those holiday chocolate calendar things to count the days until a new version of their favorite compiler will come out and can't sleep the night before because they want to be sure they can update at the very instant the release is dropped (and then proceed to complain that their favorite framework didn't update for the quirks of the new compiler in a timely manner).
Multiple times a year. If your system is well designed it should be trivial to move between different versions. As languages evolve they tend to get faster and fix more bugs. Your tests should catch any bugs if the new version breaks anything.
If you have performance concerns you can update a single server and see how it performs relative to the others. Once you're comfortable that everything is working well you can gradually migrate more servers until everything is running the new version.
Each service should have its language version pinned instead of relying on a single global version. That way you can upgrade projects incrementally.
If you're really worried you can keep both versions of the language installed at the same time so you can quickly revert in case something goes wrong.
Is a Java developer I’ve always been happy moving up as soon as possible, if I see a benefit. I was quite happy to move up to 1.5 for generics. Java eight was fantastic because you got streams and lambdas. Some of the updates in 10 and 11 will take bigger changes to the codebase to take advantage of.
But even if you weren’t using the new features, there was basically no downside to upgrading the run time. The newer version is usually ran much better thanks to improvements in threading or garbage collection. And you knew you’d get security patches, even if you ended up getting stuck on that version for a while.
As you said, libraries and frameworks can be a big issue to upgrade.
But the backwards compatibility promises of Java have been so incredibly strong it hasn’t been an issue.
The one time breakage in Java 9 is basically the first I’ve experienced in my career.
With Go: every release. Free performance improvements and backwards compatibility. It also doesn't require anything installed on the server, so it's just updating a ci script.
Not that I rush into using the newest C# language features... But C# > 3.5 has some great changes that are very easy to learn and worthwhile. The new string interpolation feature is so good I don't even allow old-style string.Formats in code reviews.
I was burned, badly, when try to port a huge ERP from .NET 1.1 to 2.? (if I remember the numbers correctly). Other projects get the slowdon, but that was truly a nightmare. That my brain trauma make forget much of it.
After that, I move very very fast. I prefer to hit "small" pains in short-term that try to do a huge jump later.
This mean that as long as I'm coding in a project (I'm contractor and do freelancing) I upgrade to whatever stable version my tools trow at me ASAP. And even minor versions or sometimes betas.
Not only language(s) - I keep at the same time different codebases in different languages, one main active plus maintenance-, I try to move everything: OS, RDBMS, IDEs, Editors, Frameworks, Libraries, etc. I probably hit "upgrade" every few days per week!
ONLY after the project stabilize and I do a few changes per-year, I stop doing that. And if the project somehow accelerate again I try to port ASAP.
How crazy is this? If the ecosystem I'm doing is nuts (ie: js) very clearly this reckless behavior show that.. QUICKLY.
...and then I need to pay more attention to my depencencies (keep them small) and choses only stable stuff.
I hit breaking changes not as often. And when see something painfull then I pin versions and keep them for a while.
This mean that I move ASAP and stay current as much as possible. I slow down when enter production, and slow down/stop again when the customer(s) stop requesting work.
This demand to use logging and have some testing, fast deployment/rollback, automate backups and use source control, very soon in the project, but this is good things anyway. (and maybe have a few VM or dockerized stuff but not as many despite more than 20 years doing crazy).
So far, this have work great for me, and never get stuck for months in rewrites like in the past. I get use to rewrite fast, that compensate to the fact that I'm a slow developer.
It's insane, a complete waste of time, and a sign that the software is turning to garbage, releasing major api breaking changes just for their own goals, but to meet the goals of the user. Same goes for frameworks to a lesser extent. If one can't point out any real advantage of upgrading to a major version other than the developers want you to, that's the sign of broken software that's about to be insecure because the developers can't stop or even slow down with it for it to be practical. At my current job, I've been working on a few apps for almost five years and they are all version one. It's almost impossible to keep up with all the upgrades and deprecated packages. The only way to justify it to the business is to point out that the only reason we need to upgrade is because the original developers have abandoned the software and therefore we cannot get security packages. The new versions for the most part, offer nothing new but demand days of research, upgrading, and testing. Ironically the language was the waist l easiest to upgrade in our case (php) because it's one of the few that values backwards compatibility and has sane major version upgrades. The frameworks ... Angular 1 is all I need to say and it just goes on from there. I wish the original developers had thought about this. Finding decent open source software to write apps that will live for more than a couple years is extremely difficult. If only we had some reputation system that rated developers and companies on long term support, that would help.
I don't know about "people", but I know that the companies and organizations that I've worked for and with for stay reasonably close to the leading edge for security and feature reasons.
And if you have a reasonable testing environment, it's not rocket surgery to figure out how much of a problem a new version might be.
Our stack is quite "boring" in that regard. Common Lisp (SBCL), Free Pascal, Perl and Go. They all run the latest versions and we never had an issue upgrading these.
Not upgrading your language every time a stable version is released seems crazy to me.
Eventually you are going to have to upgrade, and if you are 10 years behind it's going to be a huge, painful migration. If you upgrade every six months, each upgrade is easy and barely noticeable.
What you are doing seems to me like deciding not to change the oil in your car. You might save you a bit in the short term, but it could come back to hurt you in a big way.
Successive versions of Python have some really great features that keep pulling me in. Pathlib for scripting, asyncio for concurrency, f-strings for everyone. Similar in Django.
I'm sure if I had to deploy anywhere else than a server I ultimately control, I'd be a lot more conservative, but until then, this stuff makes things fun.
I’m always an early adopter for new language features on personal projects. I love playing with new things. But I use boring, reliable technology when somebody is paying me for it. As much as I like playing with shiny new things, I’m not going to bet my professional reputation on them.
Imagine you are a software developer that sells a hospital management system built on Java. You need to prove your software is built on secure technology. So if you are using Java 11, and suppose it is known that there are no more security updates, you cannot claim security.
What I understand from the article - Oracle is not supporting it Oracle 11 after 6 months, but other still will, so nothing to worry about.
I have a friend working at a company that is having “very important” discussions about this.
They need to keep up with security patches (for obvious reasons) but the six month limit has them scared. The consensus seems to be that they don’t believe they can keep up with an upgrade schedule that fast and are thus forced to pay for support from someone or hope that the community backports security fixes far enough for the rate at which they feel comfortable upgrading.
It doesn’t sound like they actually know what their upgrade rate would be, but they’re sure that it’s much slower than six months.
I am not sure I completely understand the implications of this. But, if OpenJDK is the reference implementation, and as long as someone is going to maintain Java 11, there really isn't much to worry. I worked for a company that completely relies on Java. They also relied on Apache, so they had on their roles two developers that wrote code for Apache and Tomcat. Making wild guesses here but - if OpenJDK project gets 300 companies with one contributor each to write code for them, they will continue supporting Java 11. Maintaining Java is in some way a responsibility of every company that benefits from it. Or maybe I am so out of touch with technology that I am absolutely wrong.
Waiting 6 months also does not make much sense when it comes to security patches. It seems like spending time to engineer processes to allow faster upgrades (CI/CD deployments is one popular route), would be a worthwhile investment.
Up until around 2008, clock speed was increasing rapidly and the bottleneck to systems performance kept changing. Software was being obsoleted in a mater of years. Then things started changing; evidenced perhaps by Windows upgrades suddenly becoming a lot less relevant and Apple starting to steamroll more modular computer builders like Dell.
Mark my words, there will come a day where continuously upgrading software will start to have a clearly higher cost than old, boring and stable. 2018 to me is the first year that a software platform can have had a true decade to stabilise in an environment that isn't constantly shifting and changing at a hardware level.
Maybe trends like in graphics cards will shake things up, but I believe the advantage is going to move to stable, slow upgrading, well supported platforms with large bases of well trained developer. Reducing LTS windows will be a disadvantage for the Java ecosystem.
The drive to move quickly with software wasn't to keep up with ever changing hardware, it was to respond quickly to the market. Treat every release like an experiment. The more experiments you can run the more likely you are to understand and solve the needs of your users.
Why would someone pick software that get feature releases and bug fixes on a yearly cycle when similar software is available that has weekly or daily releases.
Eh, I think we got some time for consumer performance improvements. Graphics cards and HDD/SSDs seem to have been steadily increasing (noticeably) but CPU's and RAM have not for consumers which are major bottlenecks.
My top of the line late 2013 rMBP has got 4 cores, 16GB of ram, and 512GB NVMe SSD. rMBPs just recently upgraded to 6 cores and 32GB of ram (more storage too but that isn't a big deal nowadays since speed was the biggest optimization for storage and it is still NVMe IMO). However, server CPU and RAM has increased. You can now rent an AWS x1e.32xlarge with 64 cores and 4TB of RAM and thanks to AMD, that competition seems to finally be flowing back to consumer computers (At least for CPUs).
Just look at people being amazed at threadrippers 32 freaking cores on a desktop (matches AWS x1 when you consider the x1 has dual sockets) and we still haven't passed down the gains in RAM (2TB of RAM if it matches the x1).
When those performance gains pass down to consumer computers, users will have up to 6.33 times the amount of CPU and 64 freaking times the amount of RAM!
Java moving to 6 month release cycles is good. OpenJDK is good. RedHat providing long term support is good. All of this is good.
Where I'm worried this fails is with dependencies. Also in the context of developing plugins for other Java projects. For example building a plugin for IntelliJ and the different versions of IntelliJ users may have.
Did they learn the definition of "long term support" from phone manufacturers?
.net 1.1 (I looked this up when I had to install it earlier this week...) was supported for 10 years until 2013 and as part of Windows Server 2003 (32 bit) it was supported until 2015 so it looks like they're going backwards too.
The six months security patch limit would be a DISASTER in Java world if releases still happened every 2 to 3 years like they used to. Everyone would be stuck with large periods were no security patches were available without paying.
But that’s not happening here. Yes you’re limited to six months of free security patches, but a new version comes out every six months. So you can stick with Oracle and never paid a dime is long as you stay reasonably up to date.
One could argue that LTS software is just a trap (and a particularly lucrative one). I know that this is likely a couple factors that allow me to say this namely
1. I can rule over our dependency and technology choices with an iron fist if need be
2. I live in on post 3.6+ Python as our main language and for anyone with good CD/CI you can always run your tests against the master branch and latest dev builds at least one or two versions ahead
Okay so with that said, I feel like LTS versions of software are a trap for this reason. You end up in situations where there is so much pain with upgrading that you end up spending more either more time slogging through incompatibilities in the upgrade pipeline the longer you put it off the worst this gets, or you end up in situations where you have to maintain a forked Verizon’s if the code base while you upgrade things or you have to do a lot of monkey patching and work around to just get things running (famously this is the approach GitHub used to upgrade from different versions of Rails)
The alternative is to pay money to companies that will maintain the version of what you are using, but even then you inevitably have to move forward and that leads to nasty vendor lock in
I personally believe that having a robust CD/CI platform and a well tested code base allows you to by pass this whole charade. We always have our code tested against the next next incremental release in testing, the next versions dev branch and a rolling git pull and build that tests our code base. We really do expect things to break but it lets us plan with our working code quite accurately to avoid this problem altogether and now we largely update pretty close to release cadence.
I don’t know if this helps anyone but I suggest doing software development in this fashion will save you a ton of headache. Being up to date with rolling release strategies has helped our productivity immensely because we can think about our dependencies and we have really whittled down to just a few core ones l. At a certain point we also formed some of the smaller ones and find maintaining those ourselves has been a flawless experience
Nice idea on clarifying what the word "free" means in this context (gratis, not libre) by prefixing it with a dollar sign. This is the first time I saw this, is this usage widespread?
The TL;DR is that Red Hat and IBM are going to take over from Oracle as primary maintainers of java 8 (in the form of openjdk) after January 2019. That is likely to last through at least 2022.
Going forward Oracle will be primary maintainers of openjdk for each new version of java for six months. Every third version (starting with 11) the hope and expectation is that RH, IBM, et al will take over after those six months are up and continue to support those versions for at least several years.
The author exposes his agenda by downplaying Oracle's decisions that impact Java availability to businesses and FUDing other options, e.g. he says that RedHat will push security fixes to OpenJDK first and repackage afterward, as if it was something bad.
> Build OpenJDK yourself. [...] I suspect this not a very realistic choice for most companies.
Are they saying that most firms don't have the ability to build software themselves, or is this a situation particular to Java where they don't backport security patches and most firms aren't on the latest major?
Right now I would expect that basically every company using Java is using the official Oracle version. They’ve never had to worry that they can’t get security patches for the version released 14 months ago.
Practically everyone can use OpenJDK as a drop in replacement. But right now we don’t know how long security patches will continue for each release.
I would hope most firms are on Java 8 now. It wouldn’t surprise me to see people who are still on six or seven.
Nine/ten had a compatibility break (by removing access to internal packages that no one was supposed to be using). Many companies haven’t upgraded because of that. Lots of very popular Java libraries weren’t ready or depended on other libraries that weren’t ready, so upgrading may have been difficult even if you wanted to.
That seems to be a one time thing though. At this point I don’t see why companies shouldn’t be able to upgrade relatively frequently to the latest major release.
I am not well-verse in Java world and curious about one thing.
The valuable part of Oracle JDK is the GC. For example G1 is only going to be available on OpenJDK 9. What if there's a new GC being developed, will OpenJDK have the new GC?
Kudos to RH. Here's hoping that we don't have to keep adding JIRA issues to update Java every 6 months. I have enough of this on the Javascript side as it is..
If Java is open and free, then why did Android decide to rewrite Java? I notice a lot of companies seem to avoid Java so there must be some sort of a catch.
[+] [-] euske|7 years ago|reply
Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading your library or framework can be more often, but I tend to still be fairly conservative. Upgrading your language for production twice a year sounds crazy to me.
[+] [-] shados|7 years ago|reply
I wish I was completely joking.
[+] [-] TheAceOfHearts|7 years ago|reply
If you have performance concerns you can update a single server and see how it performs relative to the others. Once you're comfortable that everything is working well you can gradually migrate more servers until everything is running the new version.
Each service should have its language version pinned instead of relying on a single global version. That way you can upgrade projects incrementally.
If you're really worried you can keep both versions of the language installed at the same time so you can quickly revert in case something goes wrong.
[+] [-] MBCook|7 years ago|reply
But even if you weren’t using the new features, there was basically no downside to upgrading the run time. The newer version is usually ran much better thanks to improvements in threading or garbage collection. And you knew you’d get security patches, even if you ended up getting stuck on that version for a while.
As you said, libraries and frameworks can be a big issue to upgrade.
But the backwards compatibility promises of Java have been so incredibly strong it hasn’t been an issue.
The one time breakage in Java 9 is basically the first I’ve experienced in my career.
[+] [-] cdoxsey|7 years ago|reply
[+] [-] gwbas1c|7 years ago|reply
[+] [-] mamcx|7 years ago|reply
After that, I move very very fast. I prefer to hit "small" pains in short-term that try to do a huge jump later.
This mean that as long as I'm coding in a project (I'm contractor and do freelancing) I upgrade to whatever stable version my tools trow at me ASAP. And even minor versions or sometimes betas.
Not only language(s) - I keep at the same time different codebases in different languages, one main active plus maintenance-, I try to move everything: OS, RDBMS, IDEs, Editors, Frameworks, Libraries, etc. I probably hit "upgrade" every few days per week!
ONLY after the project stabilize and I do a few changes per-year, I stop doing that. And if the project somehow accelerate again I try to port ASAP.
How crazy is this? If the ecosystem I'm doing is nuts (ie: js) very clearly this reckless behavior show that.. QUICKLY.
...and then I need to pay more attention to my depencencies (keep them small) and choses only stable stuff.
I hit breaking changes not as often. And when see something painfull then I pin versions and keep them for a while.
This mean that I move ASAP and stay current as much as possible. I slow down when enter production, and slow down/stop again when the customer(s) stop requesting work.
This demand to use logging and have some testing, fast deployment/rollback, automate backups and use source control, very soon in the project, but this is good things anyway. (and maybe have a few VM or dockerized stuff but not as many despite more than 20 years doing crazy).
So far, this have work great for me, and never get stuck for months in rewrites like in the past. I get use to rewrite fast, that compensate to the fact that I'm a slow developer.
[+] [-] mnm1|7 years ago|reply
[+] [-] facorreia|7 years ago|reply
> For most users, we still recommend using Java 8 for compiling (and running) Scala code.
https://docs.scala-lang.org/overviews/jdk-compatibility/over...
[+] [-] greglindahl|7 years ago|reply
And if you have a reasonable testing environment, it's not rocket surgery to figure out how much of a problem a new version might be.
[+] [-] TurboHaskal|7 years ago|reply
[+] [-] TheCoelacanth|7 years ago|reply
Eventually you are going to have to upgrade, and if you are 10 years behind it's going to be a huge, painful migration. If you upgrade every six months, each upgrade is easy and barely noticeable.
What you are doing seems to me like deciding not to change the oil in your car. You might save you a bit in the short term, but it could come back to hurt you in a big way.
[+] [-] oliwarner|7 years ago|reply
I'm sure if I had to deploy anywhere else than a server I ultimately control, I'd be a lot more conservative, but until then, this stuff makes things fun.
[+] [-] smudgymcscmudge|7 years ago|reply
[+] [-] peanutz454|7 years ago|reply
What I understand from the article - Oracle is not supporting it Oracle 11 after 6 months, but other still will, so nothing to worry about.
[+] [-] IloveHN84|7 years ago|reply
The problem is that if you stay on old language versions, you're doomed soon or later (see the world moving to Python 3.7, Java 11, C#7, Go 2,..).
If you consider then JavaScript, things are moving at speed of light. Today's framework might be ancient in a couple of months (React version??)
[+] [-] on_and_off|7 years ago|reply
[+] [-] no_wizard|7 years ago|reply
New features can make us very productive and honestly I don’t regret the aggressive approach
[+] [-] sixothree|7 years ago|reply
[+] [-] yoz-y|7 years ago|reply
[+] [-] MBCook|7 years ago|reply
They need to keep up with security patches (for obvious reasons) but the six month limit has them scared. The consensus seems to be that they don’t believe they can keep up with an upgrade schedule that fast and are thus forced to pay for support from someone or hope that the community backports security fixes far enough for the rate at which they feel comfortable upgrading.
It doesn’t sound like they actually know what their upgrade rate would be, but they’re sure that it’s much slower than six months.
[+] [-] peanutz454|7 years ago|reply
[+] [-] agibsonccc|7 years ago|reply
[+] [-] latchkey|7 years ago|reply
[+] [-] roenxi|7 years ago|reply
Mark my words, there will come a day where continuously upgrading software will start to have a clearly higher cost than old, boring and stable. 2018 to me is the first year that a software platform can have had a true decade to stabilise in an environment that isn't constantly shifting and changing at a hardware level.
Maybe trends like in graphics cards will shake things up, but I believe the advantage is going to move to stable, slow upgrading, well supported platforms with large bases of well trained developer. Reducing LTS windows will be a disadvantage for the Java ecosystem.
[+] [-] bognition|7 years ago|reply
Why would someone pick software that get feature releases and bug fixes on a yearly cycle when similar software is available that has weekly or daily releases.
[+] [-] mrep|7 years ago|reply
My top of the line late 2013 rMBP has got 4 cores, 16GB of ram, and 512GB NVMe SSD. rMBPs just recently upgraded to 6 cores and 32GB of ram (more storage too but that isn't a big deal nowadays since speed was the biggest optimization for storage and it is still NVMe IMO). However, server CPU and RAM has increased. You can now rent an AWS x1e.32xlarge with 64 cores and 4TB of RAM and thanks to AMD, that competition seems to finally be flowing back to consumer computers (At least for CPUs).
Just look at people being amazed at threadrippers 32 freaking cores on a desktop (matches AWS x1 when you consider the x1 has dual sockets) and we still haven't passed down the gains in RAM (2TB of RAM if it matches the x1).
When those performance gains pass down to consumer computers, users will have up to 6.33 times the amount of CPU and 64 freaking times the amount of RAM!
[+] [-] mevile|7 years ago|reply
Where I'm worried this fails is with dependencies. Also in the context of developing plugins for other Java projects. For example building a plugin for IntelliJ and the different versions of IntelliJ users may have.
[+] [-] scarface74|7 years ago|reply
Microsoft supports .Net Core LTS releases for three years....
https://www.microsoft.com/net/support/policy
[+] [-] flukus|7 years ago|reply
.net 1.1 (I looked this up when I had to install it earlier this week...) was supported for 10 years until 2013 and as part of Windows Server 2003 (32 bit) it was supported until 2015 so it looks like they're going backwards too.
[+] [-] MBCook|7 years ago|reply
The six months security patch limit would be a DISASTER in Java world if releases still happened every 2 to 3 years like they used to. Everyone would be stuck with large periods were no security patches were available without paying.
But that’s not happening here. Yes you’re limited to six months of free security patches, but a new version comes out every six months. So you can stick with Oracle and never paid a dime is long as you stay reasonably up to date.
[+] [-] no_wizard|7 years ago|reply
1. I can rule over our dependency and technology choices with an iron fist if need be
2. I live in on post 3.6+ Python as our main language and for anyone with good CD/CI you can always run your tests against the master branch and latest dev builds at least one or two versions ahead
Okay so with that said, I feel like LTS versions of software are a trap for this reason. You end up in situations where there is so much pain with upgrading that you end up spending more either more time slogging through incompatibilities in the upgrade pipeline the longer you put it off the worst this gets, or you end up in situations where you have to maintain a forked Verizon’s if the code base while you upgrade things or you have to do a lot of monkey patching and work around to just get things running (famously this is the approach GitHub used to upgrade from different versions of Rails)
The alternative is to pay money to companies that will maintain the version of what you are using, but even then you inevitably have to move forward and that leads to nasty vendor lock in
I personally believe that having a robust CD/CI platform and a well tested code base allows you to by pass this whole charade. We always have our code tested against the next next incremental release in testing, the next versions dev branch and a rolling git pull and build that tests our code base. We really do expect things to break but it lets us plan with our working code quite accurately to avoid this problem altogether and now we largely update pretty close to release cadence.
I don’t know if this helps anyone but I suggest doing software development in this fashion will save you a ton of headache. Being up to date with rolling release strategies has helped our productivity immensely because we can think about our dependencies and we have really whittled down to just a few core ones l. At a certain point we also formed some of the smaller ones and find maintaining those ourselves has been a flawless experience
[+] [-] needle0|7 years ago|reply
[+] [-] ToFab123|7 years ago|reply
[+] [-] bradleyjg|7 years ago|reply
Going forward Oracle will be primary maintainers of openjdk for each new version of java for six months. Every third version (starting with 11) the hope and expectation is that RH, IBM, et al will take over after those six months are up and continue to support those versions for at least several years.
[+] [-] lowry|7 years ago|reply
[+] [-] sleepychu|7 years ago|reply
[+] [-] tannhaeuser|7 years ago|reply
[1]; https://www.gnu.org/philosophy/java-trap.en.html
[+] [-] adamson|7 years ago|reply
Are they saying that most firms don't have the ability to build software themselves, or is this a situation particular to Java where they don't backport security patches and most firms aren't on the latest major?
[+] [-] MBCook|7 years ago|reply
Practically everyone can use OpenJDK as a drop in replacement. But right now we don’t know how long security patches will continue for each release.
I would hope most firms are on Java 8 now. It wouldn’t surprise me to see people who are still on six or seven.
Nine/ten had a compatibility break (by removing access to internal packages that no one was supposed to be using). Many companies haven’t upgraded because of that. Lots of very popular Java libraries weren’t ready or depended on other libraries that weren’t ready, so upgrading may have been difficult even if you wanted to.
That seems to be a one time thing though. At this point I don’t see why companies shouldn’t be able to upgrade relatively frequently to the latest major release.
[+] [-] didip|7 years ago|reply
The valuable part of Oracle JDK is the GC. For example G1 is only going to be available on OpenJDK 9. What if there's a new GC being developed, will OpenJDK have the new GC?
[+] [-] wheresvic1|7 years ago|reply
[+] [-] pejrich|7 years ago|reply
[+] [-] TJSomething|7 years ago|reply
[+] [-] kjeetgill|7 years ago|reply
[+] [-] littlesheephtpt|7 years ago|reply
[+] [-] hyperpallium|7 years ago|reply
[+] [-] exabrial|7 years ago|reply