4 ms·

I think the problem is one of economics. The SV culture made it valuable for startups to amass a large amount of users. Where as before this bubble started, i

by hasenj 9y ago

I think the problem is one of economics. The SV culture made it valuable for startups to amass a large amount of users. Where as before this bubble started, it was more profitable for development shops to build (and sell) software that anyone can use to host their own site/forum/whatever. This might not be the entire solution, but I think it would be a step in the right direction: We need more products that are developed for people to deploy on their own private servers. They have to have some very compelling points that I think are still lacking in many existing solution: - They have to be really really fast. Nothing in "python" or "nodejs" or whatever. - They have to be really really easy to deploy. No requiring a separate database server such as mysql. Just use SQLite. Also, no copying over of tons of files. Just a single executable. All other data should live in the database (sqlite file). Maybe have two database files: one for user generated content, and one for bundling application resources (images, etc). I'm not exactly sure what's the best setup, but something along those lines. - They have to be profitable for people who develop them. This is more of a cultural issue. I love open source, but requiring all software to be "free" means that it's much more profitable to create a product for yourself only and try to lure as many users as possible, just like facebook. To this end, I think something like the physical source initiative makes a lot of sense: if you buy the software, you have the right to make changes to it. But you don't have the right to also copy it and distribute it.

wickawic 9y ago
sidebar: lots of easy to enjoy things are implemented in 'slow' interpreted languages. This site, for one.
- hasenj 9y ago
  Which I think is a big mistake, because even if it ends up being used in a low traffic site, it ends up complicating the installation process. Where as a compiled language not only would run fast but also have a very simple setup: just copy over the exe and run it. Nothing to configure. No dependencies to install.
  - deleted 9y ago
    [deleted]
  - noobiemcfoob 9y ago
    Many applications I've used that come as an exe are hardly that easy to install and configure. Inevitably, something breaks because of my machine's particular configuration. On the development side, building to that magical executable is an even bigger nightmare. Most packages in python or nodejs? Install and run through package managers just fine.
    - jjawssd 9y ago
      > Many applications I've used that come as an exe are hardly that easy to install and configure. Python and Node interpreters are EXEs that are NOT easy to install and configure for 95+% of end-users > Inevitably, something breaks because of my machine's particular configuration. Indeed. Like a screwed up $PYTHONPATH > On the development side, building to that magical executable is an even bigger nightmare. I do not understand. > Most packages in python or nodejs? Install and run through package managers just fine. This implies you are familiar with WHICH interpreter you are calling and that you know where it is installed so you can call it. None of this is easy for end-users.
    - hasenj 9y ago
      The more you depend on things to be right in the target environment, the more chances you have of breaking things. Having a statically linked binary will not always magically solve this, but it's a great step in that direction. The other step is not relying on any external servers or services, e.g. postgresql, redis, etc. The rest just boils down to programmer discipline. Never introduce something that can potentially cause a headache to the end user. If you're building on an interpreted language, you can't really do that. You will always at least require the user to have a specific version of python/node/whatever. This can get complicated if the user has a different version, so now you have to introduce a virtualization layer that can manage several different versions of the environment. These tools are always annoying to use. Not to mention that some packages could have native dependencies (e.g. a python library having a dependency on a c library) and this is almost always a source of headaches.
deleted 9y ago
[deleted]

by hasenj 9y ago

wickawic 9y ago

sidebar: lots of easy to enjoy things are implemented in 'slow' interpreted languages. This site, for one.

hasenj 9y ago
Which I think is a big mistake, because even if it ends up being used in a low traffic site, it ends up complicating the installation process. Where as a compiled language not only would run fast but also have a very simple setup: just copy over the exe and run it. Nothing to configure. No dependencies to install.
- deleted 9y ago
  [deleted]
- noobiemcfoob 9y ago
  Many applications I've used that come as an exe are hardly that easy to install and configure. Inevitably, something breaks because of my machine's particular configuration. On the development side, building to that magical executable is an even bigger nightmare. Most packages in python or nodejs? Install and run through package managers just fine.
  - jjawssd 9y ago
    > Many applications I've used that come as an exe are hardly that easy to install and configure. Python and Node interpreters are EXEs that are NOT easy to install and configure for 95+% of end-users > Inevitably, something breaks because of my machine's particular configuration. Indeed. Like a screwed up $PYTHONPATH > On the development side, building to that magical executable is an even bigger nightmare. I do not understand. > Most packages in python or nodejs? Install and run through package managers just fine. This implies you are familiar with WHICH interpreter you are calling and that you know where it is installed so you can call it. None of this is easy for end-users.
  - hasenj 9y ago
    The more you depend on things to be right in the target environment, the more chances you have of breaking things. Having a statically linked binary will not always magically solve this, but it's a great step in that direction. The other step is not relying on any external servers or services, e.g. postgresql, redis, etc. The rest just boils down to programmer discipline. Never introduce something that can potentially cause a headache to the end user. If you're building on an interpreted language, you can't really do that. You will always at least require the user to have a specific version of python/node/whatever. This can get complicated if the user has a different version, so now you have to introduce a virtualization layer that can manage several different versions of the environment. These tools are always annoying to use. Not to mention that some packages could have native dependencies (e.g. a python library having a dependency on a c library) and this is almost always a source of headaches.

deleted 9y ago

[deleted]