Hacker Newsnew | past | comments | ask | show | jobs | submit | mpweiher's commentslogin

Who says they don't?

And who says that asking for your password is to gain entry?


Yes, "no obligation to admit" means they don't have any obligation whatsoever, and that includes doing so for any reason they see fit and not having to disclose those reasons (if any) to you.

It is exactly the same as "I don't have to let you in".


No, it isn't.

For example, I do not have an obligation to let people into my house. I can choose to let them in or decline them entry. But there are certain preconditions I cannot apply. I cannot, for example, say "you may come into my house only if you murder my neighbour". That's because I'm legally bound not to induce people to commit murder. It would obviously be disingenuous to say this means I have an "obligation to admit" them.

It's the same with immigration. They actually are legally bound in certain ways - an immigration official can't assault you for instance. It's not hard to imagine them being legally bound not to search people's phones. That doesn't mean "they have to admit people".


You're confusing yourself with irrelevant analogies. You can say, "you may come into my house only if you give me your unlocked phone," and an immigration official can't assault you because there are certain protections granted to foreigners against being randomly assaulted. It's also not hard to imagine them NOT being legally bound not to search people's phones, and if you're trying to say someone's breaking the law here then it's your burden of proof.

I am not confused :-)

Of course I can say that. I can say "you can't come into my house if you're black" too. The point is that it's unethical. It would be unethical for me to search your phone before you entered my house, too. This is not complicated, I'm not sure why you're having trouble understanding it.


> But there are certain preconditions I cannot apply. I cannot, for example, say "you may come into my house only if you murder my neighbour".

How is that a relevant argument?


Because the thing we're arguing about is whether it's ethical to apply certain preconditions to entering the US. What's unclear about that?

This is not some debate competition where you try and come up with useless analogies to try and win the contest.

Your house has nothing to do with this.

The United States does have some rides about what border agents can and can not do. They can not sucker punch you, for example. They can request to see the contents of your phone and if you refuse they can choose to refuse you admittance into the country.

It’s not a question of fairness.

For what it’s worth I’m very much in favor of immigration and people visiting the United States, but this country and all others have the right to admit or not admit whomever they choose.


This looks really interesting...but why WASM-only? Naively it seems like WASM-ification would be a 2nd step, after lib-ification.

Obviously missing something...


If I understand correctly, what this project does is take the actual postgresql sources, which are written in C, compile them to wasm and provide typescript wrappers. So you need the wasm to be able to use the C code from js/ts.

Yes. I would like to use the code as a library from something other than js/ts.

You can use it in Rust if you like. I've used pglite through wasmer before. Also [pglite-oxide](https://lib.rs/crates/pglite-oxide) is pretty usable.

Sounds you only need to create the APIs for calling into WASM if so, so as long as your language of choice can do that, you're good to go.

That adds extra unnecessary complexity. The code is written in C. There are C compilers for all CPUs. So just call the C code from <other language that's not JS>.

Well, a project has scope.

Looking at the repo, it started as postgres-in-the-browser. An abstract interface with C and wasm as targets is just more scope.

But it looks like the hard part of patching postgres to librar-ify it is already done agnostically in C.

So you just need to ctrl-f for "#if defined(__EMSCRIPTEN__)" to impl those else branches and port the emmake file to make.


So compile it and use it?

WASM means you only need to develop for one target run time. That's my guess as to why.

Yeah... I was super excited by this project when it was first announced--and would even use it from Wasm--but since it ONLY works in Wasm, that seemed way too niche.

Why is Wix horrible...or why does it create horrible sites by default?

Curious, I haven't tried it.



That was kind of par-for-the-course back then.

LISP had it, Smalltalk had it, Unix dc/bc had it.



> EF Core is truly one of the best ORMs I've ever used. That said, I regret that decision and won't be using it again for any new projects.

Hmm...there appears to be an interesting story and/or reason there...care to share?


It helps to go to the classics.

...

Expected Benefits of Modular Programming

The benefits expected of modular programming are: (1) managerial--development time should be shortened because separate groups would work on each module with little need for communication: ...

On the criteria to be used in decomposing systems into modules, D. L. Parnas, 1972, https://dl.acm.org/doi/10.1145/361598.361623


>> most impressive part of Smalltalk ecosystem is the structure of the image

> The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution.

I'd say these statements are both true. The image concept is very impressive and can be very useful, it certainly achieved a lot of bang for very little buck.

And it also was/is one of the major impediments for Smalltalk, at least after the mid 1980s.

The impressive bit is shown by pretty much the entire industry slowly and painfully recreating the Smalltalk image, just usually worse.

For example on macOS a lot of applications nowadays auto-save their state and will completely return to the state they were last in. So much that nowadays if you have a lot of TextEdit windows open and wish to make sure everything is safe, you kill the program, you don't quit it.

Also, all/most of the shared libraries and frameworks that come with the system are not loaded individually, instead they are combined into one huge image file that is mapped into your process. At some point they stopped shipping the individual framework and shared library binaries.

User interfaces have also trended in the direction of a an application that contains its own little world, rather than editing files that exist within the wider Unix filesystem.

The image accomplished all that and more and did so very efficiently. Both in execution speed and in amount of mechanism required: have a contiguous piece of memory. Write to disk, make a note of the start pointer. On load, map or read it into memory, fix up the pointers if you didn't manage to load at the same address and you're ready to go. On G4/G5 era Macs, the latter would take maybe a second or two, whereas Pages, for example, took forever to load if things weren't already cached, despite having much less total data to load.

But the drawbacks are also huge. You're really in your little world and going outside of it is painful. On an Alto in the mid to late 1970s I imagine that wasn't much of an issue, because there wasn't really much outside world to connect to, computer-wise, and where would you fit it on a 128KB machine (including the bitmap display)? But nowadays the disadvantages far outweigh the advantages.

With Objective-S, I am building on top of Cocoa's Bundle concept, so special directories that can contain executable code, data or both. Being directories, bundles can nest. You can treat a bundle as data that your program (possibly the IDE) can edit. But you can also plonk the same bundle in the Resources folder of an application to have it become part of that application. In fact, the IDE contains an operation to just turn the current bundle into an application, by copying a generic wrapper application form its own resources and then placing the current bundle into that freshly created/copide app.

Being directories, data resources in bundles can remain standard files, etc.

With Objective-S being either interpreted or compiled, a bundle with executable code can just contain the source code, which the interpreter will load and execute. Compiling the code inside a bundle to binaries is just an optimization step, the artifact is still a bundle. Removing source code of a bundle that has an executable binary is just an obfuscation/minimization step, the bundle is still the bundle.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: