zebra9978

There is also Gitbucket - https://gitbucket.github.io/gitbucket-news/gitbucket/2018/05...

Now with LFS, code review, etc features. Built on the JVM - blazing performance.

is this the same technology that Numerai uses... or is it multi party computation (https://mortendahl.github.io/2017/04/17/private-deep-learnin...) ?

We are extremely worried about the future of Docker Swarm as well. We love Swarm - but we are seeing most work out of the Docker team is to give a migration path to kubernetes. A huge number of docker swarm networking bugs are not being worked on.

We will be happy if Docker talks about Swarm becoming a management UX for K8s - but we need visibility. These are production orchestration systems. The migration path is not easy.

And seeing what Docker Co is doing with Cloud, it is not very comforting to trust that they will do the right thing with Swarm.

Twitter users are up in arms because of the decision to retire production systems with a 2 months notice - https://twitter.com/thomashermine/status/976398123215065088

https://twitter.com/garethdiz/status/976188140670017536

https://twitter.com/LenioLabsLLC/status/976201790482915328

Are you guys planning to migrate gitlab to golang ? I think the biggest feature that everyone wants is better performance.

Is the migration path that tough ?

what I dont understand is that gitlab raised a very large amount of money - can it not pay a team in parallel to port it to golang or java ? Maybe the gitbucket or gitea teams are up for hire.

Suggest gitbucket - https://gitbucket.github.io/

blazingly fast (a single war file - just run "java -jar gitbucket.war" to get started) and has a very nice UI. A plugin system enables you to extend the functionality (including CI) ... and a very active dev community.

https://gitbucket.github.io/

isnt training in tensorflow more effective than doing it via spark ?

https://github.com/nuxt/hackernews

hi, im helping build a fairly vanilla ecommerce site in either reactjs/vue. I want it to be entirely server-side rendered with high SEO visibility. However.. (and this is the big point), have the same APIs exposed for mobile apps as well.

How do I do this ? Any templates to explore this pattern ? It is fairly straightforward to do this in rails, but in the world of react/vue, it seems that the whole community is geared towards rich client-side applications with low SEO.

is anyone using tensorflow or caffe2 on the mobile ? We are trying to build something on the android.. but it seems there are no real-life deployments using caffe2 or tensorflow on the mobile.

I really like the UI paradigm built by gitbucket - https://gitbucket.github.io/. Its like they took Bitbucket and made it better. On that note - I cant believe how unusable Bitbucket is.

P.S. And obviously love the fact that it is a single jar file deploy.

is this for US banks ? I'm assuming not.

It provided us the coordinates of all the texts and all we had to do was look for texts similar to an Account number and IFSC from a cheque book. Using some regex it was easy to find closely matching strings

Could you explain what you mean by this ? We are trying to read shopping receipts, but I have ZERO background in image processing... so have been trying to figure out what to do. I have been trying to use Google Vision API though.

The one which worked best for us was a custom designed filter using Otsu’s Thresholding principle.

Is this where you pre-preocess the image to make it readable ? How does one do it - are these specialized tools or can I do this in python (like http://www.scipy-lectures.org/packages/scikit-image/auto_exa...)

the title has been made politically correct - the actual title is "Why Kotlin Is Better Than Whatever Dumb Language You're Using". I wonder if that was intentional editorial oversight.

any particular reason you are using BSD license ? With all due respect, this does not cover a patent grant like the Apache license and could be a poison pill for companies to adopt.

I see.

incidentally the embedded DNS feature is fairly extensively leveraged by kubernetes - it takes of the situations where you dont want to muck around with underlying /etc/hosts (on the actual metal) and do your changes only on the containers.

But I'm hearing what you are saying more and more - Docker Inc is having a huge PR problem. Docker Swarm may actually be good, but people are generally disliking the organization itself.

You dont see these kind of answers with Fleet, Mesos..even Openstack. Docker Swarm is a genuinely sweet piece of tech.. so this is rather unfortunate.

I have deployed several clusters with kubernetes and with Swarm. I think my wording was hyphenated at the wrong place. Swarm has a new yml file format - the compose v3 which is pretty damn awesome. Kubernetes has had yml files for a while, but the gap in simplicity/usability is massive.

Which is what my point was with minkube and kubeadm and kompose - for swarm, you use a single tool for either a single node cluster.. or a multi node cluster. Even more, kompose was invented to read from the same Docker Swarm compose file format - because it is so intuitive.

I'll go one step further - kubeadm does not actually have high availability support, so you actually have to use kargo or kops to reasonably deploy in production.

Kubernetes introduces a lot of upfront complexity with little benefit sometimes. For example, kargo is failing with Flannel, but works with Calico (and so on and so forth). Bare metal deployments with kubernetes are a big pain because the load balancer setups have not been built for it - most kubernetes configs depend on cloud based load balancers (like ELB). In fact, the code for bare metal load balancer integration has not been fully written for kubernetes.

Now, my point is not that kubernetes sucks - I think its a great piece of tech. But its around why do people think Docker Swarm will die.. or that it sucks? Because, relatively speaking, while kubernetes NEEDS all kinds of complicated orchestration tools (and consultants!) to set it up .. Swarm on the other hand is damn easy to setup by a developer building his first stack.

Is Docker Swarm the heroku to Kubernetes AWS ?

What do people generally think about Docker Swarm ? The new deployment using .yml files is pretty cool : https://www.infoq.com/news/2017/01/docker-1.13

In fact, IMHO kubernetes has tried to do something similar with .. but it is not engineered ground up for simplicity. Which is why it has MULTIPLE tools for this - minikube, kubeadm, kompose - but nothing matching the ease of use of docker and its yml files.

The last survey showed 32% of the polled used Docker Swarm versus Kubernetes' 40% - and this is back when Docker Swarm was highly unstable. https://clusterhq.com/2016/06/16/container-survey/#kubernete...

Are people here using Swarm ? what have your experiences been like.

There's also gitbucket built in scala. The UI is much nicer than gitea.

https://gitbucket.github.io/gitbucket-news/gitbucket/2017/01...

running it is simply java -jar gitbucket.war

this is very cool!

yes - you should revise your opinion. Thirtybees mailing list is a Mailchimp signup... not usenet. Please double check.

slack or gitter is atleast a two way street.

very well.

could you atleast put up the gitter and allow us to sign up there. mailing list feels very "commercial"

look i understand your struggle. but you will HAVE to make a call. your points below about "not having to worry about zero days like wordpress" and "not having an MVC" is incompatible with your statemnt of "we will do bugfixes for next 6 months and go from there".

I would even go to the extent of questioning any success you think you will have with the bugfix approach.

Prestashop inc has 9 million USD of funding. Your reason of existence will vanish the day that Prestashop fixes the few bugs that you have. What do you think will happen then ? Will you yourself continue on this fork... or will you say "oh well, the Paypal module works on prestashop 1.7 again"

If you are doing this, then do this for the reason you want to do it subconsciously - all the MVC stuff you are dreaming about.

Once you have users in a platform it is easier to get them into a big upgrade than to try to get users from scratch, or get the to migrate.

There is zero incentive to stay. The advantages of your "new" platform are so minimal that people will instead make and buy new plugins for 1.7 . In fact sorry for being blunt, but the existence of your fork is just as long as it takes for all agencies to port their code to Prestashop 1.7.

If your users migrate, they will force you to never break compatibility. So you will basically become Prestashop 1.8 . There is no possibility of a grand plan later.

thank you for clarifying that.

However, I think after reading the comments below that the scope of the project is to maintain backward compatibility with the agencies/authors of plugins in the Prestashop ecosystem.

What we were looking for is something that was trying to do new in the webshop ecosystem. Even I misjudged your "lack of MVC" comment below. My perception was that you were bringing together a lot of people from the Prestashop community and building something new with modern day best practices.

Using an ORM is the smallest of them. MVC is another. asset pipeline could have been a third.

But if you attempt any of this.. you will risk breaking backwards compatibility with any number of plugins out there. Which is why I'm doubtful you will try to do anything new. The way I see it is that you will maintain a bugfixed release of Prestashop 1.6 with incremental changes to support the plugin ecosystem out there.

Personally, I think you are aiming too low. You want to make something better than Prestashop 1.7 which is why your holy grail is to maintain backward compatibility and fix some plugins (like the Paypal one you talk about). But from what I have seen, your real competition is the Shopify of the world. Even Magento 2. Not sure if you have seen the docs, but Magento 2 has started adopting best practices out there:

1. composer for dependency management - http://devdocs.magento.com/guides/v2.0/install-gde/prereq/in...

2. database migrations - http://devdocs.magento.com/guides/v2.0/install-gde/install/c...

where is the github repo ... the github organization ?

there is no link to any source code anywhere. It may be an oversight, or a hesitation to open it too early. But here at HN, it gives me an uncomfortable feeling for a cabal that may bait-and-switch.

For example, I have zero idea of whether you are going to use a MIT license or Apache or whatever. Why is this so secretive ?

We have been looking to throw our weight behind an open community platform that can compete with magento. Im hoping you guys can be that... but you need to be open right from day zero.

P.S. oh and I second the ORM comment. Like seriously. It will be a horrible mistake not to use one.

are you looking for any data scientists ? sorry if you are not -because you mentioned "instant decisioning".. but you didnt mention any components of a data science stack.

quick question - did you consider using jruby ? I see on your docs you mention that you use certain libs with native extensions... but 20 mil should go a long way towards resolving those.

how about building out a single jar based deployment based on jruby ? For example, mingle is built on jruby (ruby on rails) and packaged as a easy to install jar file [1]

[1] https://www.thoughtworks.com/mingle/news/2015/02/18/Forty-Mi...

jruby will be higher performing and will use overall lesser memory in general (yes.. the jvm takes up quite a bit of RAM during startup). Running a jar in production using jetty is a breeze.