Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Brick

brick.mozilla.io

Post reply on HN
Print view View original

81–90 of 122 posts

Re: Mozilla Brick

#81

Post by randallsquared »

davexunit wrote: post #67
antocv wrote: 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…

Package management at the systems level is a completely different problem from package management at the application level. An externally-facing server application is ideally a self-contained system of its own which should be installable on any modern kind of system without regard to whatever is or isn't on that system already, beyond the bare minimum. Trying to resolve library dependencies between two externally-facing applications is pointless; there should be no effect of one on the other.

In the days when space and bandwidth was expensive, a lot of compromises had to be made, but with many current language ecosystems, the cost of maintaining separate infrastructure is trivial, so we shouldn't be continuing to make our lives more difficult by deferring to the system package manager.

The sibling comment brings up Nix, but the only reason that looks like a good solution is that it happens to make all libraries application-specific libraries (if I understand correctly), which fuses the two problem domains. Nix excepted, however, I think it's a mistake to conflate them.

Re: Mozilla Brick

#82

Post by potch »

qewrffewqwfqew wrote: post #18

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...

This is a project under active development, and was created to address of the need of mobile app developers who expect some form of UI toolkit for building mobile webapps.

Re: Mozilla Brick

#83

Post by jeffreyrogers »

hmsimha wrote: post #28
qewrffewqwfqew wrote: post #18

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.

That's just good business. Google is a company that's run for profit and is ultimately answerable to its shareholders. Google's job isn't to perform a social good, it's to continue making money. If it has areas of its business that are net losers (with no hope of eventually performing) then it has an obligation to do something about this.

For a good example of a business that divested its underperforming businesses to the great benefit of its shareholders, look at General Dynamics beginning around 1994.

Re: Mozilla Brick

#86

Post by morgante »

VeejayRampay wrote: post #64
sp332 wrote: post #59

Earlier quoted context omitted.

Servo has nothing to do with Firefox.

You're right, I stand corrected. I was under the impression that Servo would end up being the web browser engine powering newer versions of Firefox (or any other flagship Mozilla browsers to be) and from my more extensive reading after reading your comment, I appear to be mistaken. The underlying point I was making though (if it still stands) is that the good folks at Mozilla are not exactly sitting on their collecti…

> The underlying point I was making though (if it still stands) is that the good folks at Mozilla are not exactly sitting on their collective ass, they are in fact trying really hard (and the bleeding edge way) to make the web better.

I never claimed that they're sitting on their collective ass. They're certainly trying to make the web better, but by running in a million directions at once (due to the lack of direction) they end up going nowhere.

Re: Mozilla Brick

#87

Post by ForHackernews »

randallsquared wrote: post #81
davexunit wrote: post #67

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…

Package management at the systems level is a completely different problem from package management at the application level. An externally-facing server application is ideally a self-contained system of its own which should be installable on any modern kind of system without regard to whatever is or isn't on that system already, beyond the bare minimum. Trying to resolve library dependencies between two externally-fac…

Ugh. I think there's a lot of sense in this comment, but it still seems horrendously wasteful to install multiple, redundant versions of libraries just to maintain separation between applications.

Hell, space and bandwidth are cheap: Let's just distribute all of our applications as 2 GB binary VM images.

Re: Mozilla Brick

#88

Post by jessaustin »

vertex-four wrote: post #70
jessaustin wrote: post #63

Earlier quoted context omitted.

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.

One is that you can easily specify dependencies on packages not written in the language your package is written in, in a way that's machine-readable. Imagine if I could do "npm install some-framework" and it'd automatically build and install the relevant versions of node.js and MongoDB as well.

This is what I meant by "scripting hooks". I have something like the following in package.json for various projects:

  "devDependencies": {
    "bower": ">=1.3"
  },
  "scripts": {
    "postinstall": "bower install"
  }
This way I never need a global install of bower, nor do I ever really need to use it directly. I don't see why something similar couldn't be set up for any other npm-able package manager or build tool. A bit of googling seems to indicate that npm can update node using e.g. the "n" module. That module or another like it can of course be a dependency in package.json.

Re: Mozilla Brick

#89

Post by wpietri »

potch wrote: post #80
nanoscopic wrote: post #65

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.

I'm a big fan of "ship early, ship often", but you have to set expectations properly. If something is not ready for prime time, you should signal that. Call it v 0.7, say it's a beta, label it as a "labs" product. Say up front where the known weaknesses are, and say what audience you want.

I also strongly recommend working with a small, carefully selected audience to begin with. Typically only a small percentage of your eventual audience will put up with the rough edges of a work in progress. Getting the average audience member involved early on is frustrating for both sides. You get a lot of feedback on things you a) already know about, and b) are intentionally avoiding for now. And they waste a bunch of time on stuff that wasn't intended for them.

Re: Mozilla Brick

#90

Post by vertex-four »

jessaustin wrote: post #88
vertex-four wrote: post #70

Earlier quoted context omitted.

One is that you can easily specify dependencies on packages not written in the language your package is written in, in a way that's machine-readable. Imagine if I could do "npm install some-framework" and it'd automatically build and install the relevant versions of node.js and MongoDB as well.

This is what I meant by "scripting hooks". I have something like the following in package.json for various projects: "devDependencies": { "bower": ">=1.3" }, "scripts": { "postinstall": "bower install" } This way I never need a global install of bower, nor do I ever really need to use it directly. I don't see why something similar couldn't be set up for any other npm-able package manager or build tool. A bit of googl…

This isn't machine-readable, for a start - I can't see what your package actually depends on without reading through your postinstall script. I also can't write a script to convert it automatically to a .deb or a NixOS package or whatever else, because I can't figure out what its dependencies are. I can't easily say "I want this package and all its dependencies on a DVD".
Post reply on HN