HN user
Whatever.
What happens when a developer can't publish a security update because they don't have 2FA enabled for a popular package? I was almost in this position. I don't have a phone, I don't have 2FA enabled and am not looking to do so. It seems like a 2FA mandate is going to ensure that people lose access to their accounts and won't be able to publish updates at all.
The VPS we're running on has 60GB of RAM which should be plenty but the ingest program needs more work to use less memory so it stops crashing when denormalizing multipolygon relations, which involves denormalizing ways which fetch nodes... all referenced by ID which has not much locality spread across the pbf file. And if you write to temporary storage it can use a lot of disk and denormalization based on the on-disk format can get really slow. It's just all very tricky to get working well within reasonable time constraints (less than a week of processing ideally) and a reasonable memory footprint.
It's similar how with a torrent you can start seeking into a particular spot in a file and start playing by requesting particular chunks at that spot. Some clients like webtorrent support this behavior but it changes the dynamics of the network somewhat if many clients do this kind of thing. You can build some supplementary peer info to help the process along for different p2p networks depending on if they let you create side-channels or let you make more explicit connections to peers. For peermaps, the database is file and directory based so most of that peer tree traversal should be handled already by the network. And there are more ways to optimize the connections with additional tricks once you get the basics working with a somewhat slower and less sophisticated transfer method.
The website hasn't been updated in a while and the stack somewhat diverges from what is written there but we're very hard at work making all the pieces fit together. The p2p database (eyros) works pretty well with only some transfer size improvements left. The database is fully symmetric and runs fully in the browser with a ~400kb wasm build (will work on getting this down later). And the rendering stack works pretty well. The main hurdle at the moment which I have been working on is the ingest phase which consumes planet-osm.pbf and writes into the spatial database (eyros). I can process all the nodes in 1 hour and all the ways in 35 hours on a not very expensive vps but processing the relations I still run out of memory. Probably in the next few weeks I can get this ingest phase working and we will have an initial data release. There is still some rendering work with polish and label rendering but it basically works.
The main initial benefit for the project is to have completely free embeddable web maps hosted p2p (using ipfs, hyperdrive, webtorrent) where you can entirely customize the rendering. Then later the benefits of the fully symmetric nature of the database will start to make more sense and the project has the potential to become less centralized on open street map servers and data. For some prior work that I and other people who work on peermaps have worked on check out https://mapeo.world/ and this very old writeup I made about an early version of the osm-p2p database. The experiences of working on that project and prior versions heavily informs how the current peermaps stack works.
You can check out a more up to date version of the progress on this talk we gave for speakeasyjs recently: https://www.youtube.com/watch?v=P7X7C-door4
Or here is a slightly old slightly broken version of panning across a processed version switzerland using the end-to-end stack on my laptop (it looks better now) https://www.youtube.com/watch?v=gHEmmQ6GnDI
We (cabal devs) have had many discussions about supporting i2p out of the box and this is a high priority in the project road map.
Many projects[1][2][3][4] in the dat ecosystem use kappa-core[5] for multi-user applications on top of hypercores (the low-level append-only log used by dat). kappa-core is designed around the kappa architecture where the logs serve as the historical record and primary source of truth (so you get version control) and materialized views ingest the logs to answer application-specific queries.
Some nice properties of the kappa-core implementation of this architecture are that:
* works fully offline by default and many of the apps (especially mapeo) are designed for very offline use
* device to device replication is first-class
* you can completely rebuild the materialized views from the log data whenever your schema changes (very nice way of handling database migrations)
* there's a lot of flexibility in how you design the materialized views and an ecosystem of views on npm you can use instead of writing your own crdts
* works in the browser
There is also some progress in the ecosystem for sparse mode where content downloads from other feeds are driven by application-specific queries.
There is a kappa-core workshop[6] that covers some of the introductory topics.
That's not really a fair comparison. Just because something is "baked in" doesn't mean you can't get similar functionality from other libraries in a more ala-carte fashion.
location: hawai'i (utc-10)
remote: yes
willing to relocate: no
technologies: webgl, js, node, c++, glsl, linux, web
cv: https://substack.neocities.org/cv.html
email: substack@gmail.com
Looking for remote webgl, p2p, data viz, and mapping projects.
I'm particularly interested in work that ties together industrial, engineering, CAD, hardware, physical simulations, and field work with computer software. Preference for web tech.
Programming for 17 years, 12 professionally.
How is a command hierarchy where a board of investors appoints a CEO fair to the people who actually built the company?
Rollup is a good tool. You can get the same benefits in browserify using [rollupify](https://www.npmjs.com/package/rollupify) or using [tinyify](https://github.com/goto-bus-stop/tinyify) which can do tree shaking on commonjs as well as ES modules.
And there is already a browserify transform to compile inline rust to webassembly for browser code: https://github.com/browserify/rustify
These things build on each other over time and learning a language is not exactly easy, especially if you are starting out. An important aspect of the transferability here is that you can go from programming a jewelbot in c++ to programming other microcontrollers. You don't have to learn a completely different language and toolchain to continue exploring programming on a different platform.
I think the real C++ part is so important because it respects the abilities and intelligence of children to participate in the adult world using a real (yet approachable) technology that is also used in industry. This also makes these skills earned poking around with a fun toy transferable to solving their own problems, doing coursework at university, and later on entering the technology labor market. Other programming toys aimed at kids like NXT graphical programming or scratch don't have the same transferability and I've noticed that kids see right through that.
GDP has its own limitations, as it measures aggregate economic activity and does not take into consideration things like wealth distribution, environmental impact, unrenumerated labor. Further, imagine a society where everyone must pay for something that used to be free, like breathable air. If air becomes commodified, GDP goes up, but quality of life goes down as something that was previously a public good enters the realm of private profit. Extrapolate for various kinds of state-run services.
https://en.wikipedia.org/wiki/Gross_domestic_product#Limitat...
The sun is also very intense when it shines and it dries out clothes very quick. We have problems because the sun dries out the soil too much for plants so we have to put them in shadier areas. I live in an area with 300+cm of annual rainfall.
Yes I also live in Puna. Are any of you open to using https://www.scuttlebutt.nz/ ? It's an "off-grid" social network.
It sounds like the refrigerator is the problem here:
"But they still have rainy weeks where they run out of power and have to run their gas-powered generator to keep the refrigerator from spoiling."
You don't need to run any other appliances all night when the sun isn't shining. Also, why would you even have a microwave, toaster, and ELECTRIC dryer? Those all use obscene amounts of power.
I live off-grid and we run laptops (using boost converters) and lights directly off 12v DC. A big part of making an off-grid system work is reducing your consumption drastically in ways that you can't even do if you're plugged into the grid.
Pubs don't follow everyone on the network. People set them up and give out invites to their friends.
You don't need to trust the security of pubs. Validation of messages happens through cryptographic signing and public messages are public anyways. You also don't need to trust that pubs will be online much because your followers will also help host your content.
Your computer will only help host data that was hosted by people that you follow. If you don't want to spread content that you disagree with, don't follow people who post such content.
Winco is a privately-held company with an ESOP (employee stock ownership plan). Employees do not have voting rights. This is better than most private companies, but cooperatives provide voting rights in how the company is run which I think is more important.
Collective action is hard, particularly when tech companies form and dissolve very quickly and turnover is high. In addition to unions, worker ownership through cooperatives is another avenue for better conditions. In worker cooperatives, workers own the business, so business objectives are much more aligned with labor. Cooperatives don't have to worry about management union-busting or moving production elsewhere.
Consider that in a private company, surpluses are paid out to executives and shareholders. How is that not "inefficient"? Meanwhile, workers are paid a subsistence wage of however low the company can get away with paying. In a worker-owned, worker-managed business, those surpluses could be spent on higher wages, lower prices, or increasing productivity. Without having to generate profits for investors and shareholders (who contribute no labor to the enterprise), wouldn't that make a firm much more "efficient"?
Much of the Amazon basin is covered in clouds most of the time. Landsat 8 doesn't have good coverage.
Offline is not a mere feature you can bolt on to existing architectures because you are really building a distributed system. Architectures that work well for distributed systems and especially p2p architectures thrive in this environment. Elsewhere in these comments people are discussing command queues, but this idea presumes that servers are somewhat reliable and that all operations need to go through a centralized point of control and failure. Instead, you can take this idea further and implement a kappa architecture (sometimes also called "event sourcing") where you maintain a log locally on every client which is the source of truth, not a server. When a network connection is available, you can replicate the log to a server or directly to other clients. You can build indexes (materialized views) that sit on top of this log to answer queries more quickly than reading the entire log out every time. You can also blow away these indexes and rebuild them from the log whenever your requirements change (migrations).
Unfortunately the web is missing a few pieces that would make it a very good platform for fully p2p, distributed apps. Service workers are a good start, but they have a 24-hour upper cap on max-age of the service worker itself, so users can't trust on first use (TOFU) and then be more secure against kinds of active targeting. The suborigin specification and iframe sandboxes for distributing apps offline and p2p would be much more useful for offline sandboxes if they didn't require that a server send an http header. These will become much more important as the web bluetooth API matures, which can allow distributing user data and application updates in a totally offline environment.
Even without being fully offline, it's very odd that when an automatic update to android or windows comes down the pipe, people in remote areas download the exact same bytes from servers in America over and over again, all over a thin pipe. They could fetch that data from each other and save a lot of money on bandwidth and data caps.
Graeber is an avowed anarchist, so I don't think he's very keen on planned economies. People are forced into labor market participation because they can't meet their basic needs other ways, the police will squash these alternatives with violence.
If you are actually interested in what Graeber has to say instead of making up strawman arguments, you can read "Utopia of Rules".
Another alternative that is not often discussed in technology circles is to form cooperative businesses where workers wholly own the business and make democratic decisions about its governance. Why should the workers, who produce the value, not be paid according to their contributions? Why do we need management to tell us what to do and siphon off the surplus profits in the process?
You can build virtual dom trees or use real dom nodes using something like https://www.npmjs.com/package/morphdom . Tagged template strings let you build these features in without custom language extensions. See also:
* https://www.npmjs.com/package/hyperx * https://www.npmjs.com/package/yo-yo
Also keep in mind that javascript engines have a built-in mechanism for including multi-line strings with a powerful substitution engine: tagged template strings (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). The upside of template strings is that you can run your code directly in node or electron without using extra tooling first. It is possible and not hard to use tagged templates with react, although few people do. It's more common in some other frontend ecosystems.
One of the features for yarn mentioned is better offline support, but you can also do this with vanilla npm:
npm install --cache-min Infinity