Live data from Hacker News

Mozilla Brick

brick.mozilla.io

71–80 of 122 posts

Re: Mozilla Brick

#71
post #59

Earlier quoted context omitted.

Making Firefox non-sucky? Isn't https://github.com/servo/servo good enough for you? Creating a new programming language and using it to build a modern browser rendering engine? I understand that Mozilla is going lots of different directions with its projects but come on, they can't be accused of not putting the effort to make the web better.

Servo has nothing to do with Firefox.

And Phoenix had nothing to do with SeaMonkey. Funny how things work out.

Re: Mozilla Brick

#72

Earlier quoted context omitted.

You completely misunderstand the point. "Another package manager" doesn't matter. People can and should use the package manager of their choice (why should I break pip?). The point is to have common ground between all package managers.

Could you talk about the advantage(s) you perceive of a "common ground between all package managers"? After using npm a bit I think scripting hooks in a package manager that can call other package managers enables many good things.

Well, for one thing, new package managers could be implemented without having to worry about the infrastructure. The server software could be shared between all linux distributions and would be applicable for any sort of "bundle server"; think game addons, firefox/chrome extensions, skins for your favourite software and what not.

Re: Mozilla Brick

#73
post #45

Earlier quoted context omitted.

yea because it's much better to have closed, restricted app markets (like Apple, Google, Microsoft ones) than web standards.

You means the standards where each browser version has its own view of the world, or the standards where the applications get executed behind a HTTP(S) key hole?

This is missing the point of Firefox OS. It's not meant to go head-to-head with other mobile OSes, it's a development platform for new phone-oriented HTML APIs. When Firefox OS started, there was no way for a web page to use a phone's webcam, or to act as the phone's dialer. The existence of Firefox OS means that other mobile OSes can use their standardized and tested APIs to make HTML more powerful.

Re: Mozilla Brick

#75
post #21

Can we get a package manager for package managers? There is so many already, its hard to keep track what names come from what repositories of what package managers. It used to be so simple, yourDistroPackageManager install whatever, now there is x2000 versions of packageManager.

Package management needs to be solved at the systems level. Rather than having a new package manager for every language and every extensible program, the problems that make our systems package manager (apt, yum, etc) unsuitable for the task need to be addressed. The biggest problems to me are unprivileged package management (no sudo) and support for multiple "profiles" (think virtualenv, rvm, gemsets). Projects such…

"Projects such as GNU Guix or Nix solve the problems quite nicely, IMO."

So long as you define the problem space as "package management for POSIX systems," and in the case of Guix you can scratch OS X and I think the BSDs off the list, too. If your package manager doesn't run on all of Windows, Linux and OS X at a bare minimum then your package manager is not solving the problems of Node.js, Python, PHP, Perl, Ruby or any other cross-platform runtime.

Re: Mozilla Brick

#76

I clicked through all of the examples, and I would never use any of these components. They are very plain, they don't provide much functionality, and the functionality they provide is lackluster ( unappealing ). As others here have stated, I also couldn't tell if some of the examples are even working or not; they are that bad. If you are looking for a fine set of interworking components that provide a refined look an…

Good. Its not just me. I almost wonder if this was a draft site never intended for release and someone mistakenly or prematurely posted it.

Re: Mozilla Brick

#77
post #28

wth is going on at mozilla? There seems to be a lot of excitement to create stuff, without much attention to whether it's needed .. or where the lifecycle goes beyond creation. http://www.ianbicking.org/blog/2014/09/professional-transiti...

It looks like their following the Google model, except without needlessly pulling projects that don't gain enough traction yet serve a niche market.

For an example of a pulled Mozilla project, see Skywriter/Bespin: https://mozillalabs.com/en-US/skywriter/

Re: Mozilla Brick

#79
post #75

Earlier quoted context omitted.

Package management needs to be solved at the systems level. Rather than having a new package manager for every language and every extensible program, the problems that make our systems package manager (apt, yum, etc) unsuitable for the task need to be addressed. The biggest problems to me are unprivileged package management (no sudo) and support for multiple "profiles" (think virtualenv, rvm, gemsets). Projects such…

"Projects such as GNU Guix or Nix solve the problems quite nicely, IMO." So long as you define the problem space as "package management for POSIX systems," and in the case of Guix you can scratch OS X and I think the BSDs off the list, too. If your package manager doesn't run on all of Windows, Linux and OS X at a bare minimum then your package manager is not solving the problems of Node.js, Python, PHP, Perl, Ruby o…

Sigh. Well fine, if you're stuck on Windows then language-specific package managers are much better than nothing. But on POSIX systems, we can do so much better than the current mess.

Re: Mozilla Brick

#80

I clicked through all of the examples, and I would never use any of these components. They are very plain, they don't provide much functionality, and the functionality they provide is lackluster ( unappealing ). As others here have stated, I also couldn't tell if some of the examples are even working or not; they are that bad. If you are looking for a fine set of interworking components that provide a refined look an…

Hey, Brick project member here. Completely agreed, the styling for these components is not where it needs to be. We're a small team that works in the open, and like to ship.
Post reply on HN