HN user

nanoscopic

394 karma

Software Engineer. Speciality: Metaprogramming. Github: https://github.com/nanoscopic Hacking stuff: https://livxtrm.com

Posts5
Comments147
View on HN

This should be re-titled. It is inaccurate. It implies that some notable percentage of MacOS/iOS is published. Nothing of the sort is true.

They publish a tiny minority of those systems that they are forced to due to the licenses of components they use in those systems.

My JSON parser ( github.com/nanoscopic/ujsonin ) has these things:

0. Looks essentially the same as JSON

1. Core data types, and customizable data types can be added easily.

2. Arrays, Objects, and arbitrary nesting.

3. Comments ( both /* */ and // format )

4. Multiline strings ( by default; carriage returns are no problem within strings )

5. It is JSON with relaxed restrictions and slight addition for actual named types.

6. I've written C, Perl, and Golang implementations so far.

While Apple is very restrictive and controlling, they aren't as controlling as many imply about running your own/custom apps on phones.

You can sign up for a free developer account and sign apps onto your iDevices for free. ( 3-apps at least, for 1 week at a time )

If you pay for a developer account you can sign many more apps to run on your devices as you like. This includes apps that would not pass the store approvals.

I agree it is a hassle to have to install apps that way, but at least they do allow it.

I'd like to know this as well. My guess is that you may have to install it on your device before it gets dropped from the Apple store.

Definitely have a cloud backup of your device enabled in case you need to ever reset your device so that you don't lose the app.

If you want to install it on another device things become more complex...

Alright. This is a fair point. I go way out of my way to discourage underage visitors to the erotica website I run, and I do agree that there is tremendous sensitivity in the current era towards the notion of anything sexual involving children.

Despite that, I don't think such sensitivity is unreasonable. I do believe that children are sexual from quite an early age, and that that should be accepted and encouraged from a sexual wellness perspective, but simultaneously I think children are abused very frequently even in this era and we should continue to do everything we can to protect them from abuse.

I still see plenty of "stories of my childhood" on erotica websites, and I don't see anyone going out of their way to shut them down. Example: solotouch ( not my website, but a common example with many such stories )

Another legal example that comes to mind is the man who was convicted for importing obscene hentai manga. I personally believe hentai should be considered free speech but that is certainly not the case in the legal arena right now.

My point remains that I believe the world is very accepting of many types of erotica that I had previously thought would be highly frowned upon.

I will point out that under the miller test ( the main law concerning this in the US ), textual material that is artistically meaningful as writing does not constitute illegal writing. I myself shy away from writing any erotica describing explicit sexual activity of minors, but I still believe it to be legal if written well enough... I does though fail 2 of the 3 prongs on the miller test:

1. The average person would agree that description of explicit child sexual activity is illegal. ( fiction wise at least; I think accounts of childhood activity may be deemed acceptable by many normal folk )

2. Description of child sexual activity is patently offensive.

In the case of Lolita, for the most part, the book isn't terribly explicit in nature. It also ensures its legality by being an instance of well written fiction.

Other applicable law is "activity contributing to the delinquency of minors". So, it isn't unreasonable for something that is otherwise legal to be illegal ( for good reason ) if it is used to encourage minors to engage in sexual activity ( with adults or for the entertainment of adults )

Essentially, the world is very accepting of erotica in many forms. The world simultaneously has many laws to attempt to protect children while maintaining the general acceptance.

The actual article title is "How Would the Publishing World Respond to Lolita Today?" The title here is a small bit from the article. Unless the submitter here is the author I don't think it's appropriate to link this article under this title.

The article consists of the story of how Lolita was published in the US mixed with background on the political setting of the era it was published in.

The overall claim of the article seems to be that Lolita is still politically interesting and sparks debate.

I disagree with this conclusion. The world is all too fond of sexuality, and especially with controversial sexuality.

I am actually the author of a somewhat popular website involving written erotica, and what I've found is that controversial erotica is wildly popular regardless of the specific content. You could publish all manner of twisted crap today and it would mostly be met with praise.

There are, of course, puritanical haters that will go out of their way to whine and cry about it, but the world has reached a point where it is broadly understood that written erotica is freedom of speech and trying to ban it or make it stop is pointless.

Efficiently wielding weapons is not terribly difficult. It just takes practice. My parents bought a number of guns and became quite proficient at firing them accurately within 2 years.

I have many relatives and friends who are amazing at skiing. My cousin posts pictures every winter of the sick lines he skis down.

I'm neither an excellent marksman nor skier, but I don't think it would be difficult to become excellent at both given an excessive amount of free time within a few years.

I can though drive a manual very well, own a sports car, and have no fear of drifting it.

A coworker of mine was a pro skydiver, and recommended it to everyone. I've met other skydivers as well; it's supposedly easy and affordable.

Another coworker owned his own plane. Planes are costly but he wasn't James Bond rich...

My brother-in-law owns a few hundred guns including fully automatic weapons.

Being James Bond is a bit idiotic in real life as he engages in a lot of high risk stuff, but it is certainly doable.

Obligatory self promotion: https://github.com/nanoscopic/mtsc

It is a tool I created myself for figuring out the contents of layered docker images.

It does these things:

1. Compares two docker images to see exact file differences

2. Diffs the contents of two directory structures

3. Views contents of a docker image without mounting it or using docker itself

4. Generates a standalone index of the contents of a docker image

5. Determines the resultant layer composition of a directory within a docker image

6. Extracts a specific pathed file from a layered docker image

It is extremely helpful when trying to determine the exact differences between two different builds of the same Dockerfile.

"JSON" parser author here.

I don't believe in the spec at all, because as pointed out in the article, the spec is not precise enough. The spec also puts undue burden on the parser.

The spec should absolutely say whether the first or last key has precedence when duplicate keys appear. I don't think the spec should simply demand the parser to error on duplicate keys as that isn't helpful. If such an error exists, there should still be a way to parse the structure and get the data. A duplicate key shouldn't cause complete parse failure. It is recoverable.

To resolve the problem with people placing comments into dummy values ( or duplicate keys ), the JSON spec really needs to implement a feature set key / flag key. Something like: { "_flags":["comments"], ... }

This would allow for extensions to be reasonably supported aside from the fact that none of the parsers will initially do anything with this extra key.

Another flag would be "plainstrings", which would tell the parser NOT to parse escapes in any way and just deliver string data as is. This is what my parser does, as there are too many pitfalls in parsing escapes consistently, and you then also have to code in how to write those escapes back out. This may be passing the back onwards, but I view it as division of responsibilities. Why should the parser be responsible for and required to understand unicode and all its complexities?

Another flag would be "type.[some type]" to indicate presence of a type and the need to be able to parse it. The way I implemented this in my parser is this: { key: [type name].[type representation] }

For example, hex data: { key: x.4FE310B2 }

These sorts of things would address the issues brought by the article.

Who am I, though, kidding... Cooperation doesn't exist in the community, no one will change their parsers to do as I suggest, and I'm likely to get downvoted just sharing my ideas. Carry on uncaring world.

What motivation would Google have to pay any attention to this request?

The only one I can imagine is that Google wants to get some positive PR out of it. Other than that it seems to me like Google will just ignore this as they ignore anything else they don't see as in their benefit to exert effort on.

Don't Panic 6 years ago

I agree that adding error checking at every possible error location and then passing up those errors is tedious, but it is a direct result of Golang essentially being a "modern C".

In the case you describe it sounds like it was particularly painful due to the multi-threaded nature of the software.

You didn't call it out directly but I feel like the inability of Golang to do polymorphism makes it more difficult.

If the result of something is simply a message, and that message can be either a normal data type or an error, then you don't need to always additionally return an optional error. This is why I prefer the idea of message passing languages over direct procedural languages.

It is still possible to do this somewhat in Golang using channels and/or queues, channels can tend to get clogged and freeze up in my experience.

I've had good experiences using Mangos ( Golang nanomsg implementation ). If you use inproc queues, you can do multi-threading in a language portable way. Then, if you decide to replace a processing component with something other than Golang, it is relatively easy to do so.

Those features are interesting but I fail to see how the headline is nothing more than misleading.

I opened the link expecting to read about some legitimate issue with iOS 14. The entire article is about one updated app on iOS 14, the health app.

The title should be "The new iOS 14 health app is driving me mad".

Also, I'm not clear on why the author wrote the post. It seems like an admission of being obsessive compulsive.

Just ignore the new features in the updated health app. Problem solved?

The example in this article is horrible. The author will not accept bug reports without payment for "support". I'd posit that no reasonable open source project has such a position.

Sure, without payment there may not be any expected turnaround time or immediate response, but being unable to submit a bug without paying is absurd.

OpenSUSE MicroOS 6 years ago

I used to work for Suse. During my time there MicroOS was broadly considered to be a joke and abandonware by my coworkers. I worked on the very team developing their k8s solution ( the entire team of which was fired due to the recent acquisition )

My recommendation, which is, of course, my personal opinion, is to stay away from MicroOS.

Open source is profitable in two ways:

1. If the work is ultimately for a company you are working for fulltime and getting paid from the start. This is the case with IOS support for DeviceFarmer. I work fulltime for T-Mobile. I am thankful to them for allowing the majority of the resulting software to be open sourced. The reason they allowed it to be that way, and wanted it from the start, is so that we can benefit from users using the software, finding bugs, and reporting them. There have been contributions from the open source community to it as well that have been very helpful.

2. By providing paid support for an open source project. There is a great need right now for someone ( and/or many someones ) to work with companies to get DeviceFarmer setup and working well for their needs. I do this a little bit on the side myself, but it is tricky because I don't have much time remaining after my day job to do so, and I have to be careful not to let it become a conflict of interest.

DeviceFarmer as a entity is a collection of key personnel who have been maintaining OpenSTF. I believe all of them are fulltime employees of various companies that use it internally and contribute to it to address their own needs. I joined the core team as a result of writing IOS support for it ( I say "writing", despite also porting in a large chunk of IOS support from other open source contributors; mrx in specific )

Right now DeviceFarmer isn't a legal entity. There is no company or non-profit currently. It is just a bunch of developers cooperating. We have considered creating a non-profit company for it, but it has not been done yet. The members of the group are spread out internationally.

The original main author(s) of OpenSTF formed the company HeadSpin out of it, and offered it as a commercial project. Very recently the company collapsed as a result of internal corruption, but the project itself lives on. Really they had abandoned OpenSTF 2-years ago anyway. The rebranding to DeviceFarmer instead of OpenSTF is to move the project to being open and no longer restricted by HeadSpin.

HeadSpin themselves refused to ever accept contribution of IOS support into the OpenSTF project, because IOS support was one of the main differences in their commercial offering. They refused to ever open source that portion of OpenSTF. Forking the project was necessary to allow this. Essentially the entire community has moved to the fork and abandoned OpenSTF. The crumbling of HeadSpin sealed the deal and OpenSTF is essentially no more.

I'm not an Apple user. The reason I've spent the last year and a half developing an open source solution to support Apple devices is because it is a challenge and is profitable. I view myself as a sort of technological mercenary. I go where my skills are needed.

I don't own a personal mac laptop, nor do I use an iPhone. If Apple gave me a macbook pro and an iPhone I wouldn't use either. ( other than to develop software that requires those )

I do though believe in making required technical things easier for others. It is a good feeling making something possible with IOS devices that hasn't been done as open source previously.

Creating and testing IOS apps isn't something that will cease to be just because hardcore developers dislike the closed Apple ecosystem. The people who fund Apple, in my opinion, aren't hardcore geeks. They are the normal folk in the world.

My only request to Apple is to please listen to what the developers want and provide some of the information I need so that I can in turn improve the development experience for the developers that are already paying into their ecosystem.

Sitting on your high horse saying "I don't like the way big companies function" doesn't pay the bills or convince anyone you are a good engineer who will stay professional regardless of your personal feelings.

If you manage to get anyone from Apple to speak with you send them my way also. I am the author of IOS support for DeviceFarmer ( previously OpenSTF ). Part of that support involves getting video of the screen over the USB connection which uses the same undocumented pathways that libimobiledevice uses. I've been attempting to find someone at Apple to support the open source efforts for nearly a year to no avail.

What I would like Apple to support is fetching the raw h264 stream in a documented fashion, rather than forcing one to use AVFoundation and get pre-processed frames/data. Only allowing decoded video makes it impossible to scale. ( having many devices connected to a single mac all streaming video )

It would also be awesome if they would open up and document all the protocols and operations that the lockdown protocol supports. I doubt that will ever happen though.

Please release my rewrite / serialization library for Apache Avro. I wrote it in 3 different languages for Amazon when I worked there, and went through all sorts of discussions to have them release it, and they refused for no meaningful reason that I could see.

The only reason I was ever given was "we use it and think it is great therefore we won't release it." The implication was "If what you wrote was junk we'd let you release it."

Needless to say I never tried to get Amazon to release any of my software during my time there after that, because the response was so poor.

Edit: If Amazon releases my code, I'll be happy to add a tiny credit to Amazon in Notices.Txt and in no other way be thankful to Amazon.

Amazon has very high internal costs and they also reinvest a lot of the money that is made into the company itself.

The best way to view their "not paying tax" is from that perspective. If you have a business, and you make no "profit" because you reinvest every dollar of gross income back into the company, then it makes sense to be taxed much less by doing so.

Additionally it is a misunderstanding that Amazon "doesn't pay tax." I looked into this myself after seeing all the hatred to Amazon about it, and they actually pay many types of tax and in high amounts. Everyone simply fixates on the taxes they are able to minimize.

Every large company does their best to maximize profits and minimize losses for whatever reason. It is soulless but that is how companies function and is sensible from a certain perspective. I think they should also be "human" and not merely logical, but from a strictly logical viewpoint it makes sense to treat employees as disposable tools and get as many tax cuts as you can.

What consequences? I think almost everyone knows Amazon is evil and heartless, but most of us continue to use Amazon to buy things anyway because they have the things we want at low costs.

I wrote a long response to this. Hacker news then presented me with a message "Your comment was too long".

Short version: Think what you will. My story serves as a warning to anyone who thinks you can survive the Amazon hell. I may have issues of various sorts, but no one should have to tolerate the "Amazon way" or be subjected to their insanity.

I can chime in that a lot of this rings true for me. I was also an SDE-II ( started as one ). I also was loaned out to other teams. I also suffered the idiocy of being locked into 2 years of work or get saddled with a huge amount of money to pay back.

Also, I consider that my child is dead because of what happened.

See https://amazonandmykid.com for the full story.

I agree with this to the extent that "open source your library" means "publish it on Github". Adding it into a package management system, be it one for a language or one for a Linux distro, is implying some level of stability and functionality. This is especially true if you choose a desirable namespace for your project on a system that doesn't differentiate by username.

Essentially; do publish all work you possibly can, simply be clear about what the software does or does not do.

I am very guilty of not doing this myself. I throw together some bit of code that is useful to me, and dump it on github with no explanation of what it does or how to use it.

As a bad example, I'd encourage everyone like me to put in a bit of effort to explain what your code does, so that when someone stumbles across it they have a way to give it a try and see it doing something.

Is the Debian "we will not hide problems" a wide German thing? I noticed the same sort of behavior described in this article while working for SUSE.

At SUSE there was a meeting held ( in Germany ) where everyone from SUSE was encouraged to speak up openly about anything they were concerned about, and told that those issues would be addressed in an open and truthful manner for all to see.

I thought it was really great to have such a meeting and ask for everyone to be truly open. The reality I encountered after speaking up openly was quite different.

While everyone was allowed to speak out openly, the real answers to many of the "going ons" was hidden. Even in said "we are being totally open" meeting upper management directly lied about specific events. I confronted said manager, was told "it was none of my business" and then later terminated over it.

It's water under the bridge, and I am happy to be away from them now... my question is simply if this sort of "well you can speak up, and then we'll use that information against you" is a common thing in the German / western world of OSS.

I'm convinced based on reading through this article. Thank you for posting it.

Things I like especially about it: It is written very logically and admits clearly to being speculation based on what information exists. The information is referenced and considered in great detail.

It mentions the "HIV inserts" article posted on hacker news previously that many here ripped to shreds and has been discounted as nonsense. I've seen that one go the rounds on facebook and have had to explain to my own friends and family that it is nonsense.

Interestingly the information suggests that the virus could have come about spontaneously in the wild at some later point. The logic is mainly about the proximity to the labs doing detailed work on exactly the same sort of virus.

TLDR for those who don't feel like reading through the very long article: Labs in Wuhan were researching essentially the exact same virus type as what is going around the globe. Virus outbreak happens to be right at the same place ( within miles ) as where the outbreak started.

[dead] 7 years ago

It's illegal. Also, sex tends to be more enjoyable when you can enjoy it regularly with the same partner ( hence marriage ).

Therefore, yes, it is unhealthy. Move along.

Summary of the article: You need an apple developer account to use the feature. Those cost $100 / euros per year.

This was a really anticlimactic reason. There are a lot of things you can do with a developer account. They are essentially just throwing this new feature/benefit onto the pile.

Whining because "I'm not an Apple developer but I still want to use the Apple ecosystem" is kind of silly in my opinion.

Yes. We all get it. Why can't we go back to the days when developer accounts were all free on every platform? Sorry. Those days are gone. Buck up and deal with it.

ITA: OMG! I'm required at many huge sites to register for the site to view content! Some of them aren't even free, I have to pay!

If you don't like those sites, don't use them. Sites as described do not constitute the "entire web". There are plenty of great still free still usable websites. There is an entire internet of them.

Believing that the whole web is just the monopolistic giants is the problem here.