I really want to like Apple (but they don't like us) - <AUTHOR> http://www.dieblinkenlights.com/blog_en/i-really-want-to-like-apple

<comment><USER2> The cable nightmare should be enough to open up anyone's eyes. There's a line somewhere that companies should not cross in their willingness to protect their investments.. Apple trying to disallow other gadgets from using iTunes is one thing. You may or may not agree with it but it does not sound too weird. Standard cables are far, far beyond that line that should not be crossed.

<comment><USER3> I'm not ready to jump on this one.

For one thing, I have an iPhone, and I have a car with Microsoft Sync. Every time I plug the iPhone into the car's USB port, it pops up "this accessory is not made to work with iPhone". And then it works anyway (except for the part where something is a little overzealous about reindexing the music on the phone, and I'm not yet sure which side that one's on).

For another, the DRM point may be more important than the author makes it out to be: there are plenty of systems where using the "wrong" cable will still work, but with significantly degraded access (I still remember the first time I had to buy an adapter box to use a DVD player with my TV). I'm not sure that "sorry, you can't do that" is any better or worse than "you can do that, it just won't be useful in any way".

<comment><AUTHOR> The author can assure you the video halts while the iPod displays that dialog ("monologue" would perhaps be more appropriate) box saying the cable is not compatible. It usually does so after a random period of time (between a couple seconds to a couple minutes) playing the video on the TV. Any subsequent attempt to play the video with the same cable results in the video being shown on the iPod screen. One workaround is to reboot the iPod and restart playback, but it is more hassle than I am willing to put up with.

It may be called "degraded usability" for some...

</comment></comment></comment><comment><USER4> I got my first Apple product - a MacBook - in December. The only way to connect it to an external monitor turned out to be purchasing an additional Mini DisplayPort[1] adapter for something like $45 - from Apple, of course, since no one else was selling it.

The ONLY product in the entire world at the time that used the Mini DisplayPort, as far as I could tell, was the MacBook. (well, maybe some of Apple's new displays). Of course the adapter wasn't included with the MacBook, and it's expensive as hell.

Not quite as bad as the linked article, but that was my first experience with Apple as a company - left a bit of a bitter taste.

[1] <http://en.wikipedia.org/wiki/Mini_DisplayPort>

<comment><USER5> I don't think that's Apple being evil, that's Apple being ahead of the curve. They've always done that and I've thought it was generally admirable, although sometimes it puts you as a customer further out on the bleeding edge than you'd like. (E.g., I was very much unready to give up PCI when Apple decided to ditch PCI-X for PCI Express. However, it was clearly where the world was headed.)

They've done the "lead, don't follow" thing consistently since Jobs came back. Ditching ADB and serial for USB; ditching SCSI for FireWire---I groaned at each one of those calls, but they turned out to generally be the right ones, just a year or two in some cases before the market was quite ready.

However, all that is quite different from the bullshit with the iPod video cable discussed in the article. That's just outright consumer-hostile behavior, and it's not traditional Apple ... it seems to be something new, which has only started to happen in the last few years, and mostly in the markets where they are dominant.

I still like a lot of Apple's products (I'm writing this on a 15" MacBook), but it's as much evidence as I need to not want to ever have Apple dominate the PC market. They're a wonderful company when they're the underdog, but a harsh mistress when they're in charge.

<comment><USER6> They did the "lead don't follow" thing before Jobs came back too when it came to hardware (indeed all the way from the beginning of the company to the present, from mice and "plug-and-play" ADB connectors to 3.5" disks to the first real consumer laptops (remember the Duo Dock anyone?) to really embracing SCSI, laser printers, and then in the recent Jobs age, USB and firewire and ethernet and DVD writers etc. etc.), it's just that their software stagnated for quite a few years and none of the next-gen software research projects they dumped loads of cash into in the early-to-mid 90s really panned out.

</comment></comment></comment><comment><USER7> FTA:

 _The point is, as much as I like Apple's attention to detail, its outstanding industrial design, I can't justify buying a product that's not really mine. Call me spoiled, but using stuff like Linux made me feel I am really in control. The netbook is mine, and nobody will make my computer do something I don't approve. If it ceases to work, it will be my fault._

This is exactly why I switched from XP to Linux rather than to OSX. I'd rather tinker with _my own_ system than be passively impressed with the feature set of _Apple's_ system.

</comment><comment><USER8> _I can't justify buying a product that's not really mine. Call me spoiled, but using stuff like Linux made me feel I am really in control. The netbook is mine, and nobody will make my computer do something I don't approve._

This should be enshrined as a sacred principle of programming, not unlike the medical profession's Hippocratic Oath: "I will not build user-betraying systems." It is not enough for us to swear not to buy them: the sheeple will. And they have the most dollars/votes. We, the programmers, must refuse to participate in their creation.

See:

"Ethics for Programmers: Primum non Nocere" <http://glyf.livejournal.com/46589.html>

"The "you don't own your computer" paradigm is not merely wrong. It is violently, disastrously wrong, and the consequences of this error are likely to be felt for generations to come, unless steps are taken to prevent it."

</comment><comment><USER9> _It's a cable! How incompatible with something can a cable be?_

Quite. Analog or not, cables carry a lot of technology these days.

To attribute this to some DRM effort is quite a large assumption. I wouldn't recommend writing off a company like Apple based on an assumption like that, considering it is almost certainly not true.

Granted, Apple does not usually go out of their way to make sure 3rd party accessories are supported on future devices. They can be a bit reckless about modifying interfaces, which tends to _accidentally_ break 3rd party products (which Apple doesn't even always know exist). Heck, they frequently break compatibility with their own older products.

I think there is a tradeoff here, though. MicroSoft is actually darn good at backwards compatibility, and Apple is good at innovation. Striking the balance is tough.

</comment><comment><USER10> Apple don't support non apple cables anymore, they do sell a cable that does what you need. Either buy the dam cable or go back to firmware 2.0. I didn't like it either, but they do have a reason to that (the octopus cable mentioned in the support forum) and they are probably going to stand by it.

Its like asking for microsoft to support their new bluetooth mice on windows 95. If I had windows 95 I would like them to, but it is not their obligation. I really wish they would support their freaking ABNT2 keyboards on macosx (which they don't, although the box says so).

There is no guarantee that something that worked before a soft/hard upgrade will continue to work, specially between major versions. Linux for christ sake dropped support for a lot of things between 2.4 - 2.6 and no one was whining about it. I mean, there is always someone whining on a linux forum...

<comment><AUTHOR> "Its like asking for microsoft to support their new bluetooth mice on windows 95"

Actually, it's like Microsoft checking whether the mouse is made by Microsoft and then refusing to work with it despite the fact it would work perfectly.

<comment><USER10> Its not that, they check to see if the cable is an octopus cable, the problem is that just apple make those right now.

</comment></comment></comment><comment><USER11> What I don't see here is any corroborating evidence that this is anything other than a bug or a faulty cable. Did the author call AppleCare? Did they tell him this was a DRM issue? Has he tried it with protected and unprotected content? Has he tried a new cable of same make and manufacture? Has he found any other users with this same problem (seems like there would be many)?

This is all basic troubleshooting that we would normally perform (or insist on being performed) before passing judgement. And yet for some reason, if it's an Apple product and you're new to the brand, you're somehow _expecting_ to be screwed. So you blame any and every error on Apple and their _evilness_.

<comment><AUTHOR> "What I don't see here is any corroborating evidence that this is anything other than a bug or a faulty cable."

As for the faulty cable, unless the fault is really small, there is no reason to believe there is one. The cable works flawlessly with other iPods that have the 1.x software. I could not find any other cables from the same manufacturer and, since it's just a cable, I threw out the box it came in without much thought of that.

I contacted Apple support, but since the cable is not made by Apple and the iPod's warranty is expired, they said I am pretty much on my own.

As for being new to the brand, I own (and have used then extensively in the 80s) a couple Apple IIs and a somewhat large collection of Macintoshes. Sadly I don't have a Lisa or a NeXT cube (working on that and gladly accepting donations), but, if that's not enough to make me a non-Apple-newbie, I certainly don't know what would.

Did you even read the article? It's all written in the first paragraph...

<comment><USER11> I read your article. I wish you'd have done my comment the same courtesy. You address none of my points. You haven't tried another cable. You haven't had the issue confirmed by support. You haven't tried with protected vs. unprotected content. You haven't found other users with the same problem... You can makes excuses for why you haven't done these things. They may even be good and reasonable excuses. But until you rule out the obvious and likely, your explanation of "my cable doesn't work because Apple doesn't like us" sounds like something of a conspiracy theory.

Also, for what it's worth, I'm comfortable labeling any new iPod/iPhone user who's most recent Apple hardware hails from over a decade ago as "new to the brand".

<comment><USER12> I did speak with Apple support. The rep told me that Apple does not support any non-Apple cables. I asked her if she meant "made for ipod or iphone" cables purchased at a legit retail store. She confirmed that they do not support any non-Apple cables after the 3.0 update.

</comment></comment></comment></comment><comment><USER13> This is not news. In 2007 it was already reported that video out stopped working in iPods unless you used a new cable with an authentication chip: [http://www.ilounge.com/index.php/news/comments/apple- locks-t...](http://www.ilounge.com/index.php/news/comments/apple-locks-tv-out- in-new-ipods-breaks-video-add-ons/)

</comment><comment><USER14> Why would anyone want to like a company?

<comment><USER15> Because capitalism is built on a series of MUTUALLY BENEFICIAL transactions. So when I buy a product - I gain something because I now have the product and the company gains because they've sold me that product presumably at a profit. The reason I buy something is because buying it makes me better off.

I like things that make me better off - therefore it is perfectly reasonable to like companies - esp ones that make important/complex things that I derive a lot of benefit from.

<comment><USER7> _Because capitalism is built on a series of MUTUALLY BENEFICIAL transactions._

It's not only that: capitalism is also built extensively on explicit or implied _social norms_ that cultivate customer loyalty to a company that makes and keeps _ethical_ as well as _contractual_ promises.

Market norms and values are what they are, but people live in social and ethical worlds, and most people expect their business transactions to be ethically as well as economically acceptable.</comment></comment></comment>


The moment of embalming: T. S. Eliot's love letters – a report from the archive - <AUTHOR> https://www.the-tls.co.uk/articles/the-moment-of-embalming/ <comment><USER2> I just heard of T. S. Eliot for the first time very recently, when I discovered this poem of his:

        It is hard for those who have never known persecution,
        And who have never known a Christian,
        To believe these tales of Christian persecution.
        It is hard for those who live near a Bank
        To doubt the security of their money.
        It is hard for those who live near a Police Station
        To believe in the triumph of violence.
        Do you think that the Faith has conquered the World
        And that lions no longer need keepers?
        Do you need to be told that whatever has been, can still be?
        Do you need to be told that even such modest attainments
        As you can boast in the way of polite society
        Will hardly survive the Faith to which they owe their significance?
        Men! polish your teeth on rising and retiring;
        Women! polish your fingernails:
        You polish the tooth of the dog and the talon of the cat.
        Why should men love the Church? Why should they love her laws?
        She tells them of Life and Death, and of all that they would forget.
        She is tender where they would be hard, and hard where they like to be soft.
        She tells them of Evil and Sin, and other unpleasant facts.
        They constantly try to escape
        From the darkness outside and within
        By dreaming of systems so perfect that no one will need to be good.
        But the man that is will shadow
        The man that pretends to be.
        And the Son of Man was not crucified once for all,
        The blood of the martyrs not shed once for all,
        The lives of the Saints not given once for all:
        But the Son of Man is crucified always
        And there shall be Martyrs and Saints.
        And if blood of Martyrs is to flow on the steps
        We must first build the steps;
        And if the Temple is to be cast down
        We must first build the Temple.

        — T. S. Eliot</comment>


Why LINQ beats SQL - <AUTHOR> https://www.linqpad.net/WhyLINQBeatsSQL.aspx <comment><USER2> > And if you need to support older databases (prior to SQL Server 2005), it > gets worse: [ _some bad SQL_ ]

If you're stuck using a database version that first came out a decade ago, you've got bigger problems than legacy syntax for pagination.

> Not only is this complicated and messy, but it violates the DRY principle > (Don't Repeat Yourself). Here's same query in LINQ. The gain in simplicity > is clear: var thirdPage = query.Skip(20).Take(10);

If you're using OFFSET / LIMIT to do paging then you're doing it wrong. See here for the real way to handle paging for _large_ result sets: [http://use- the-index-luke.com/blog/2013-07/pagination-done-t...](http://use-the-index- luke.com/blog/2013-07/pagination-done-the-postgresql-way)

<comment><USER3> Great link, thanks. Is PostgreSQL still the only db supporting that?

<comment><USER4> The right charts on slide 45 says "X" for SQLite. That changed recently: [https://www.sqlite.org/releaselog/3_15_0.html](https://www.sqlite.org/releaselog/3_15_0.html)

DB2 LUW has also decent row-values support: [http://use-the-index- luke.com/blog/2014-11/seven-surprising-...](http://use-the-index- luke.com/blog/2014-11/seven-surprising-findings-about-DB2#blog-db2intro- rowvalues)

Need to update the slides...

</comment></comment></comment><comment><USER5> I know many are going to disagree but I have come to despise almost all SQL generators unless they are as close to 1-1 as possible (aka Lukas Eder's jOOQ is acceptable in my book).

Even more controversial... I don't want to make it any easier for developers to interact with the database unless it is absolutely correct and transparent. I know.. I know... how could I say such I thing! But you see I want every interaction with the our data repository... our precious data repository... that is usually the bottleneck... I want you to know WTF you are doing when you touch it.

We (my company and probably others) are past the days of monolithic rapid prototype apps with ORMs. Now you pick a database and you learn the hell out of it because you can stick to it. Back in the day one of the reasons ORMs were so popular because companies would have to ship on premise ware that would have to work with multiple databases. With the cloud that is no longer the case. However I still think a lot of .NET shops come from the on premise mentality. Thus performance is less of concern (speed of release is more desired).

<comment><USER6> For me there are two primary reasons for having an ORM or ORM-like framework

1\. Compile time checking. I hate when I'm writing a straight SQL query in a string literal and misspell one of the column names, because everything will compile and unit tests will pass, and the mistake isn't caught until I run integration tests. I want a short edit-compile-debug cycle. jOOQ is a good example of something that helps here.

2\. Arbitrary filters. Often I have to expose a REST API where the user can add an arbitrary number of filters to their query. You can't write SQL literals for these because there's a combinatorial explosion of possibilities. So you wind up dynamically generating SQL yourself by concatenating strings in the WHERE clause, hoping and praying you don't accidentally allow SQL injection. I want an ORM to deal with that shit for me.

<comment><USER7> jOOQ helps with both 1 and 2. With jOOQ you can write something like (totally off-the-cuff code incoming, written outside of an IDE with only basic syntax highlighting, be warned, etc)

        List<Condition> conditions = new ArrayList<>();

        if (notNull(lessThan)) {
            conditions.add(MY_TABLE.MY_COLUMN.lt(lessThan));
        }

        if (notNull(greaterThan)) {
            conditions.add(MY_TABLE.MY_COLUMN.gt(greaterThan));
        }

        if (notEmpty(name)) {
            conditions.add(MY_TABLE.NAME.eq(name));
        }

        dslContext.selectFrom(MY_TABLE).where(conditions).fetch();

(This is obviously really contrived but I hope it illustrates the ideas)

We use constructions like this with jOOQ relatively frequently, especially for cases where we offer all sorts of arbitrary filter knobs (useful for internal tools especially).

In general, you can do some pretty fancy manipulation with `Condition` in jOOQ, like you can build a list of conditions and then call `DSL.or(conditionList)` to OR them all together. Stuff like that.

Source: use jOOQ in production code -- been _very_ pleased so far, other than sometimes poor documentation

<comment><USER8> I much prefer:

        var query = from c in db.MyTable
                    where lessThan    == null ? true : c.MyColumn < lessThan
                    where greaterThan == null ? true : c.MyColumn > greaterThan
                    where name        == null ? true : c.Name == name
                    select c;

Although IQueryable supports your approach also:

        var query = db.MyTable;

        if (lessThan != null)
            query = query.Where(c => c.MyColumn < lessThan);

        if (greaterThan != null)
            query = query.Where(c => c.MyColumn > greaterThan);

        if (!String.IsNullOrEmpty(name))
            query = query.Where(c => c.Name == name);

        var results = query.ToList();

</comment></comment></comment></comment><comment><USER9> It seems like an apples to oranges comparison - it is looking at the readability of code returning similar results, but it doesn't consider how these results are going to be generated, which is a major part of writing queries.

Do the LINQ examples, especially the more complex ones, result in the same or better execution plans? Maybe they do, but the article doesn't tell, and without it it's kind of inappropriate to make judgments or even recommendations.

<comment><USER10> This was my concern as well. When I saw the "query.Skip(20).Take(10)" syntax, I was wondering if the previous line that built the query variable downloaded all 15 bajillion rows in my Customers table of people whose names started with 'A' so it could get rows 21 through 30.

If it actually only ends up creating some complex sql behind the scenes to get those ten rows, how horribly convoluted did it become and wouldn't it be better to write a straight SQL query to do the same thing, even if it's a little more complicated than the pseudo code? I guess I prefer more control. If my SQL query turns out to be slow, then I can learn from that and fix it. If the generated query from LINQ is slow, I have no recourse over it.

<comment><USER11> > I was wondering if the previous line that built the query variable > downloaded all 15 bajillion rows in my Customers table of people whose names > started with 'A' so it could get rows 21 through 30.

That would be a silly thing to do. LINQ is made to be lazy. At worst it would pull the first thirty rows, twenty in Skip and ten in Take.

</comment></comment></comment><comment><USER12> I was pretty bewildered by the convoluted way they posited for selecting a subrange of rows, but then I googled around and learned that LIMIT is a nonstandard MySQL extension. Huh.

(Apparently, while LIMIT n,k is MySQL-only, MySQL, PostgreSQL and sqlite all support LIMIT k OFFSET n. So I assume this blog post is only really relevant for people who live in a Microsoft ecosystem?)

<comment><USER13> It took a while, but SQL Server 2012 introduced OFFSET/FETCH:

        SELECT * FROM items
        ORDER BY key
        OFFSET 100 ROWS
        FETCH NEXT 10 ROWS ONLY

([https://technet.microsoft.com/en- us/library/gg699618(v=sql.1...](https://technet.microsoft.com/en- us/library/gg699618\(v=sql.110\).aspx))

</comment></comment><comment><USER14> "SQL is a very old language—invented in 1974."

Not a good start. SQL is still in widespread use 43 years later because of how good it is. It's not a legacy weighing us down. Rather it has consistently proven its usefulness over and over again. Some of the constructs can feel awkward to be sure. But part of our impression of awkwardness is really just due to SQL's declarative nature, which makes the structure of queries look a lot different than the procedural languages we spend most of our time in.

But it's not clear to me from this article that LINQ is even anything different that what already exists in most every modern application platform. It provides a cleaner syntax for some subset of common query patterns. Okay. There's a ton of SQL generators out there. Is LINQ doing something _else_ for us? This article doesn't say. I don't know, and I didn't learn that from this article.

If you use C# or VB to write apps against relational databases, then by all means, use this to write your SQL. But don't pretend the SQL isn't there or isn't important. LINQ just places you one more potentially leaky abstraction away from your dataset.

<comment><USER15> > SQL is still in widespread use 43 years later because of how good it is. > It's not a legacy weighing us down.

I'm rather dubious of this claim. This is kind of like claiming the reason we use Javascript is because of how good it is. The awkwardness of SQL is not because it is declarative, otherwise LINQ would have the same awkwardness because it is also declarative. I think the real reason SQL is because database vendors have not made an effort to add support for other languages.

</comment></comment><comment><USER16> Only it doesn't. The examples given _compile_ to SQL. So you're not comparing LINQ with SQL but LINQ-to-SQL (or the entity stuff) with SqlCommand.

SQL's a pretty grim language, but it's the only language the database understands as a first-class citizen. Until someone designs a new foundation (like WebASM is doing), the rest is just syntactic sugar.

<comment><USER17> > SQL's a pretty grim language, but it's the only language the database > understands as a first-class citizen. Until someone designs a new foundation > (like WebASM is doing), the rest is just syntactic sugar.

SQL is an ugly COBOLesque veneer over an elegant relational calculus core.

But the "new foundation" you speak of already exists, and has for decades. Competing query languages based on relational calculus are less ugly – QUEL, D, etc.

Sadly, those better looking query languages have failed in the marketplace–ugly SQL won.

<comment><USER18> I have looked at D, and read some of CJ Date's books. As far as I can tell, D doesn't solve any of the actual problems with SQL, like composibility and code reuse, and just solves Date's imagined problems about not following relational theory close enough.

</comment></comment></comment><comment><USER19> It's funny how async/await has influenced so many other languages but LINQ, that in my opinion is much more interesting (specially the DB stuff) for solving down to earth problems is sistematically ignored by other languages (Python, Java, JavaScript, etc...)

<comment><USER20> In the case of Python and Java, I think it's because generator expressions and Streams, respectively, accomplish much the same thing.

Honestly, if you've seen what LINQ compiles to, it looks an awful lot like a Java 8 Stream.

Using Wikipedia's example of LINQ translation ([https://en.wikipedia.org/wiki/Language_Integrated_Query#Lang...](https://en.wikipedia.org/wiki/Language_Integrated_Query#Language_extensions)):

Written LINQ is:

        var results = from c in SomeCollection
                      where c.SomeProperty < 10
                      select new {c.SomeProperty, c.OtherProperty};

It compiles to:

        var results =
             SomeCollection
                .Where(c => c.SomeProperty < 10)
                .Select(c => new {c.SomeProperty, c.OtherProperty});

And in Java 8:

        Stream<> results = someCollection.stream()
                                         .filter(c -> c.getSomeProperty() < 10)
                                         .map(c -> new AbstractMap.SimpleEntry<>(c.getSomeProperty(), c.getOtherProperty()));

(of course, iterating over them is different; you just use a for loop in C#, but in Java you have to either use .forEach() or .collect() to a collection and then for over that)

I think Streams have more LINQ in them than most people think.

Disclaimer: it's been about a year since I've written Java 8, and this is off the top of my head (and the last time I used it, my employer's codebase had a class for pairs that was better than just SimpleEntry), so the code could be wrong.

Edit: and just for completeness... the same in Python generator expressions:

        results = ((c.some_property, c.other_property)
                   for c in some_collection
                   if c.some_property < 10)

Not very LINQ-like, but it serves the same purpose.

<comment><USER21> In the real world, MOST people are using the "it compiles to" version directly in the code. I certainly don't write the "from x in y select" version, except in the case of multiple hairy joins. Even those have become second nature at this point.

It's just more readable, and turns it into an object pipeline/functional programming style instead. The Java 8 streams were pretty much directly taken from LINQ and given their traditional functional names.

<comment><USER8> > In the real world, MOST people are using the "it compiles to" version > directly in the code

What's your source for this claim? Because anecdotally I don't see that at all.

<comment><USER22> Our codebase at work has hundreds if not thousands of LINQ queries, mostly using method syntax. I generally prefer it over query syntax except in a few cases, such when there's multiple joins or subqueries, or the when the statement is more than a few dozen lines. Occasionally a very complex LINQ statement requires using a `let` declaration which also is easier with query syntax. Luckily Resharper has an action to convert back and forth on the fly, so it's easy to use that to switch over when necessary.

I also don't use LINQ to SQL at all. It's all on in-memory stuff. I pretty much never write code like this:

        var result = new List<string>();
        foreach (var item in input)
        {
            result.Add(item.Value);
        }
        return result;

instead, using LINQ:

        return items.Select(x => x.Value);

The real power comes when you start mixing conditions:

        return items
            .Where(x => IsValidKey(x.Key))
            .Select(x => x.Value);

Or doing quick checks:

       if (items.Any(x => x == null || x.SomeValue == null))
           throw new InvalidArgumentException(nameof(items));

<comment><USER21> And now, with C#6 that last bit becomes:

if(items.Any(x => x?.SomeValue == null))

</comment></comment></comment></comment></comment></comment><comment><USER23> Elixir's Ecto is very similar to this.

[https://hexdocs.pm/ecto/Ecto.Query.html#content](https://hexdocs.pm/ecto/Ecto.Query.html#content)

</comment><comment><USER24> I couldn't help by roll my eyes at that title. ORMs and the like are great, but they still end up using SQL under the hood. LINQ is by no means the most aesthetic ORM, either (and half of the article is about much _better_ LINQ looks than SQL).

The headlines may as well read: "Why [interpreted language] beats assembly".

<comment><USER25> LINQ isn't an ORM though, is it? At least not in the traditional sense.

<comment><USER26> LINQ is a set of language features and libraries that help enable better ORMs, among other things.

LINQ to SQL and Entity Framework are examples of ORMs that use the LINQ features

</comment></comment></comment><comment><USER27> If the title says some piece of tech "beats" some other piece of tech can we just all act like proper engineers and not post it here at all and save us all some time?

<comment><USER28> I think sometimes it's worth looking at the usernames of who posts and consider whether you want to contribute to the thread.

<comment><USER29> Judging the username, or the person behind the username?

</comment></comment></comment><comment><USER30> I agree with the article and try to use write my queries with Linq instead of SQL almost always.

The article says to avoid using Linq for bulk inserts, but for years I've been using an extension method to translate Linq to a bulk insert and it works fine. I forget where I found it.

        public static class DataContextExtension
        {
            public static void BulkInsertAll<T>(this DataContext dc, IEnumerable<T> entities)
            {
                using (var conn = new SqlConnection(dc.Connection.ConnectionString))
                {
                    conn.Open();

                    Type t = typeof(T);

                    var tableAttribute = (TableAttribute)t.GetCustomAttributes(
                        typeof(TableAttribute), false).Single();
                    var bulkCopy = new SqlBulkCopy(conn)
                    {
                        BulkCopyTimeout = 1200,
                        DestinationTableName = tableAttribute.Name
                    };

                    var properties = t.GetProperties().Where(EventTypeFilter).ToArray();
                    var table = new DataTable();

                    foreach (var property in properties)
                    {
                        Type propertyType = property.PropertyType;
                        if (propertyType.IsGenericType &&
                            propertyType.GetGenericTypeDefinition() == typeof(Nullable<>))
                        {
                            propertyType = Nullable.GetUnderlyingType(propertyType);
                        }

                        table.Columns.Add(new DataColumn(property.Name, propertyType));
                    }

                    foreach (var entity in entities)
                    {
                        table.Rows.Add(
                            properties.Select(
                            property => property.GetValue(entity, null) ?? DBNull.Value
                            ).ToArray());
                    }

                    bulkCopy.WriteToServer(table);
                }
            }

            private static bool EventTypeFilter(System.Reflection.PropertyInfo p)
            {
                var attribute = Attribute.GetCustomAttribute(p,
                    typeof(AssociationAttribute)) as AssociationAttribute;

                if (attribute == null) return true;
                if (attribute.IsForeignKey == false) return true;

                return false;
            }
        }

<comment><USER31> I'm actually doing something else when updating a webshop from a remote source..

I convert all objects that i import to a big SQL Query.

Something like

First query: UPDATE table SET active=0;

Second ( big ) query: UPDATE table SET _properties_ = _values_ IF ROWCOUNT =0 INSER INTO table( _properties_ )VALUES( _values_ )

</comment></comment><comment><USER31> What i mostly like about LINQ is IQueryable. It's awesome!

I just design the IQueryable with if's, switches, ... and when i need to execute it. I use .ToList()

The IQueryable is then translated to SQL and executed it.

<comment><USER27> And then time goes by some guy comes along rips out the LINQ and fixes all that so it's performant under load with hand crafted sql queries.

<comment><USER31> And then you have no more errors in the VS Error Window ( LINQ is static typed), when someone changes the domain layer and everything goes to ____* when going into production and now you have to manually check all strings if they are adjusted..

As said before, change to pure SQL WHEN something goes too slow. You don't have to change everything. It will bite you in the __* later ;)

Gotta love static typed :)

</comment></comment></comment><comment><USER32> I currently use a bit of LINQ, SQLAlchemy, Blaze/Odo, and a few other tools, depending on the project. However, primarily I'm still writing SQL in 2017 despite want of a prettier alternative. Here's the main reasons:

* In pretty much every project I've ever worked on, there's a small, un-standardised set of database functions I rely on. I need to parse strings and dates, round to the start or end of the month or week, group and categorise values in order to build a dimension table. I've never found a SQL generator that can provide this, although I believe SQLAlchemy Core folks are working on it.

* Planners are still not so good that you can ignore them altogether. I often rely on EXPLAIN to see why things are taking seconds instead of milliseconds, and I often end up looking for ways to trick the planner. If I'm using a SQL generator, I'm now trying to trick both the planner and the generator, neither of which I have direct control over.

* If you're building a lot of complicated queries, setting up indexes and views, and so on, it's hard to get past the advantages of an IDE. Currently, the best tools are pretty much all database specific. Even just being able to quickly see your data in a tabular format is huge.

<comment><USER33> To your first point, LINQ-to-SQL can bind database functions for use directly in LINQ queries. I've used this first hand for parsing comma delimited string parameters into table values and joining from there in LINQ.

I haven't used entity framework or any newer tech beyond LINQ to SQL but I'd have to believe such a trivial feature is present in them.

<comment><USER32> You are right, and just about every ORM product gives you _some_ way to get at raw database functions. It would be great, however, if they also offered a small RDBMS-agnostic library of functionality that would generate the correct database functions.

</comment></comment></comment><comment><USER34> The outer join example is not what I'd want LINQ to do. Most of the time it would be preferable to send two queries, one to retreive customers, the other to retreive high value purchases, then do the "joining" locally.

Otherwise we're potentially fetching the customer data N times per customer (depending on the average number of high value purchases)

</comment><comment><USER35> Sigh. It's hard to know where to begin critiquing this.

I guess the TL;DR would be something like: "For constrained but not atypical data models (no N:M relationships, foreign keys explicit in the schema, etc), it's possible to have a more concise syntax than SQL, with less impedance mismatch."

But even that underwhelming statement is generous.

In the 1980s, the object database claim to fame was less impedance mismatch, and ODI's "coding by deletion", but at least ODBs coupled that with claims to superior performance for network data models.

Maybe it's just the grandiose title "LINQ beats SQL" that's so annoying. Simpler syntax would certainly be welcome for the relatively rare cases of humans generating SQL (I think most SQL is machine generated these days)... but only with a host of etceteris parabis conditions, prominently including performance.

<comment><USER35> In the 70s, when I was all bushy-tailed, I cornered Gerry Sussman at MIT to tell him about "this new relational data model and SQL language". About two minutes into the conversation I saw him looking at me like "God, why have you chosen to torture me with this idiot."

Or maybe it was the look you have when you are SURE that someone is telling you an elaborate joke and suddenly realize that no punch line is coming.

LINQ: I'm looking at YOU :-/

</comment></comment><comment><USER36> In most of the examples, it will still execute the more complex SQL against the database... however, it's somewhat easier to reason about.

That said, I tend to prefer to use the collection extension methods, over the LINQ syntax, which make more sense in my mind.

</comment><comment><USER37> There will always be 1-2 queries that can be proven to work better in an alternative query language, other than SQL. For instance, I can surely find a couple of awesome graph queries in the Cypher query language (Neo4j). Or some JSON queries in N1QL (CouchBase). Back in the days, they tried to advocate that QUEL was a BetterThing™. Where's QUEL now?

Same will be said of LINQ in a decade. Whereas SQL will still be there.

</comment><comment><USER38> SO LINQ is more terse but there were no performance metrics given. Given the same RDBMS with proper indexes, statistics, etc., all functioning properly which is quicker? I think it'd be murky if LINQ just pulls raw data to the client and then does the transformation there vs. on the server with SQL.

<comment><AUTHOR> There is a bit of an art to writing LINQ queries, but if you know what you're doing (i.e. spend a little time experimenting, with the traces turned on in EF or Linq to SQL that output the generated SQL, or a good profiler), you can write queries that are exactly the same as hand-tuned SQL. There's a little reflection overhead mapping results to types, but, you either make use of that, or have to write all that boilerplate yourself, so that's the tradeoff.

Of course, if you don't know what you're doing, you can write some monstrous Linq queries that will be dog slow and exhibit all the worst n+1 behavior, pretty easily.

</comment></comment><comment><USER39> I guess not many came across this guide.

For LINQ to other languages: Swift Java Kotlin Clojure Dart Elixir

[https://github.com/mythz/swift-linq-examples](https://github.com/mythz/swift- linq-examples)

</comment><comment><USER40> So I'll admit I'm not at all familiar with LINQ and MSSQL, but from reading this, it looks like LINQ is just an ORM?

And if that's the case, then of course it is easier and looks nicer than SQL -- that's kind of the point of an ORM.

But I could show you a whole bunch of articles about Python and Ruby and Go ORMs too.

Seems like an Apples to Oranges comparison.

<comment><USER41> It's not an ORM, more like an alternate way to write queries that's kind of embedded in the language itself (as opposed to SQL where you're putting together a string). If you're familiar with the Rails world, I'd say it's more like "Arel" than "ActiveRecord".

<comment><USER40> But Linq literally generates SQL before sending it to the server:

[https://msdn.microsoft.com/en- us/library/system.data.linq.da...](https://msdn.microsoft.com/en- us/library/system.data.linq.datacontext.getcommand.aspx)

Doesn't that make it an ORM?

<comment><USER26> That link is about LINQ to SQL, not LINQ proper

* LINQ is a set of language features and libraries that help enable better ORMs, among other things

* LINQ to SQL and Entity Framework are examples of ORMs that use the LINQ features

</comment></comment></comment></comment><comment><USER42> But LINQ is too slow comparing to vanilla SQL.

</comment><comment><USER43> There's one BIG problem with LINQ. I'll agree that the syntax is marvelous, a game changer. The problem is performance.

It's gotten slightly better over the years but compared to an ORM with less abstraction like Hibernate it's still dog slow. Every MS project I've worked on was mostly LINQ...then a folder called "dirty SQL" for the heavy stuff.

I'm not sure if it's due to the highly abstracted nature or just not making performance a priority but in my experience sane Hibernate queries are about 1/2 the speed of native SQL and LINQ is closer to 1/50.

I hope and pray they can make the performance at least within an order of magnitude of raw SQL or even Hibernate so I can say goodbye to SQL forever.

<comment><USER31> Use LINQ for development and production, when you need performance use Dapper. It shouldn' be too hard if you follow the DDD pattern.

You can always use DataContext.Database.SQL(query) ofc

<comment><USER43> > You can always use DataContext.Database.SQL(query) ofc

that's pretty much our MO :) . Never used Dapper, how reliable is it? I ask because we use StackExchanges' Redis client for C# and it mysteriously crashes even after untold hours of debugging

<comment><USER31> Actually, haven't had any issues with it. So, it's safe to say that i find it very stable.</comment></comment></comment></comment>


Show HN: IHP, a batteries-included web framework built on Haskell and Nix - <AUTHOR> https://ihp.digitallyinduced.com/ <comment><USER3> I really enjoyed your introduction. For the HN readers who enjoy summaries in the comments, they open with a 10-12 sentence introduction, but the second sentence sets up the core philosophy and primary value proposition:

> Back in the early days of the web, when server-side rendering was still a > thing, javascript was sprinkled here and there to make a few parts of your > web app just a little bit smoother.

It's "built on top of Haskell and Nix."

The more detailed 20 minute introduction and documentation is located at: [https://ihp.digitallyinduced.com/Guide/](https://ihp.digitallyinduced.com/Guide/) I think the "recipes" section provides some illuminating examples.

The creators make the following claims about durability at the end of their introduction page:

> Lots of frameworks are already gone a year after launch. Especially in the > fast moving JS world. But don't worry about IHP. We have been using it at > digitally induced since 2017. It's actively used by us and our friends and > partners. Even without external contributors we will build new features and > do periodic maintenance releases in the future. We have big plans for IHP > and as a profitable and independent software company we have the ability to > actually execute them over the longterm.

I'm very skeptical of web frameworks / toolkits. While I only work on personal projects, I tend to try to use pure HTML first, then add CSS where needed, then add JS where needed, then add backend where needed - always striving to minimize the amount of the next layer. This project seems to be targeted to someone with my preferences.

I'll definitely be keeping an eye on it, and poking around with it.

<comment><USER4> > For the HN readers who enjoy summaries in the comments

This was a good reminder that I should at least skim the article first.

On the other hand I wonder if there's a way for HN/Reddit to help people write summaries in comments. (Perhaps even recursively!)

</comment></comment><comment><USER5> IHP includes a GUI to build postgres schema - this is really cool and much appreciated. Databases have been existing for ages now and so are the GUI tools to manage them. However, it's unfortunate that most web frameworks fail to provide functionalities like this.

Working in similar space[1], I have been talking to many early customers. Right from somebody who knows enough programming to product managers to CTOs, the idea of having a GUI within web framework and to have CRUD APIs ready with just few clicks gives them an amazing head start in building web apps. Getting past this redundant phase of creating basic CRUD with no hassle means - <USER2> can devote their energies on the business side of things. It will not be wrong to imagine in few years this workflow will become a norm.

[1] : [https://github.com/xgenecloud/xgenecloud](https://github.com/xgenecloud/xgenecloud)

<comment><USER6> > It will not be wrong to imagine in few years this workflow will become a > norm.

I hope so too but we had this in different forms since the early 80s already (maybe earlier) and it never got big for some reason.

<comment><USER5> >> we had this in different forms since the early 80s already

Could you name them, happy to check them out.

</comment></comment></comment><comment><USER7> Important bit missing from the title: this is using Haskell (and Nix).

IHP is supposed to become the Django/Rails/Phoenix of Haskell.

I've been using Django professionally for since 2013, but have started using IHP a couple of weeks ago. It's still quite early but with surprisingly few rough edges, i.e. the developer ergonomics are much better than I expected. It has great documentation that is improving rapidly (as opposed to many other Haskell libraries, which provide little more than API docs or even just the typed function definitions) and offers a refreshing take on database management and migrations.

Some of its killer features:

\- HSX, a JSX-like template language that looks like HTML while providing type safety

\- Auto live reloading without the need to setup anything

\- Documentation with examples: it lets you query the database without learning about monads

\- it defines |> for you ;-)

\- type-safe, composable SQL queries:

      projects <- query @Project
        |> filterWhere (#userId, userId)
        |> filterWhere (#deleted, False)
        |> orderBy #createdAt
        |> fetch

<comment><USER8> I get the type-safe part, assuming it means the eventual query will produce a predictable result set compatible with wherever it's being read into (I'm not a haskeller), but a) SQL is easy enough to learn syntactically b) there are good reasons not to create dynamic SQL; it's better to write it such that a query plan can be cached (for scalability). Which is very likely possible here but is it done?

I wonder if the person who wrote this understands SQL to sufficient depth. Not saying either way, just asking.

<comment><USER9> You really can't avoid dynamic SQL if you need it for your software. For example, if you give your users the ability to select filters to apply to the data fetched from the DB, you will have to dynamically create the SQL unless the number of possible filters is extremely low. Above a certain scale this might not be feasible for predictable performance, but not everything has billions of rows.

The choice isn't to use dynamic SQL or not in these cases, it's whether you implement the feature that requires dynamic SQL or leave it out entirely.

<comment><USER10> Though interestingly (as you acknowledge via "if you need it") that also tends to be the only time a traditional site/app does need it: a /search endpoint.

</comment></comment></comment></comment><comment><USER11> I think enough time has passed that we're collectively forgetting the good reasons why so many moved from server side rendering, which I would say it was mostly the difficulty in make complex uis. Then it became a trend, now going old school seems appealing.

Anyway in my particular case if I had any project that was a good fit for server side rendering I would probably now go with php and some libraries but probably no framework. I've been looking at some "weirdly coded 90's style php projects". An while the code is a terrible mess there's also the magic that I can read everything that's happening pretty quickly because it's just there or in a file next to it and not hidden in a library and a sub-library with calls to functions that I never seen before.

<comment><USER12> I think the problem here is that you are setting up a situation where it is some binary choice between the insane complexity of SPAs and everything that entails and some random 90s style hand rolled PHP file.

There are a whole bunch of options between those two extremes and I can't for the life of me think why people don't talk about them more often.

For example, I think the new Hey.com implementation hasn't received anywhere near the level of recognition that it probably should have.

It's an entire email application with a single set of screens that power all web, desktop and mobile apps, does so with all the speed of an SPA, has no need for advanced state management, has the ability to push live updates on a per component basis on any screen and does it all in under 40kb of JavaScript.

Seriously go and look at the source code. I've only seen a tiny number of people talking about it like in this post [https://dev.to/borama/a-few-sneak- peeks-into-hey-com-technol...](https://dev.to/borama/a-few-sneak-peeks-into- hey-com-technology-iii-turbolinks-frames-5e4a)

But to me the past few years of SPAs are starting to look more and more like a mistake to me where they became the rule when they should have probably been the exception.

<comment><USER13> Unfortunately it is hard for me to comment on the hey.com web app as they currently have restrictive registration.

The benefit of building with a de-coupled JS frontend (SPA) and an API is that it can extended and adapted far easier than using server-delivered HTML.

If you have an API that delivers JSON/Protobuf/whatever, you can easily make new interfaces to that backend. If you are currently delivering a web app in HTML/JS, but decide you want a native Mac/iOS app written in Swift, you'll just end up building an API anyway.

Sure, there are plenty of websites that wont ever need additional interfaces, but if your goal is to make an app that _can_ easily have new interfaces added to the mix, de-coupling is the way to start in my opinion.

<comment><USER14> You make a good point, and this is one of the reasons why I really like the Phoenix web framework (of the Elixir ecosystem). It firmly guides you towards building applications where Phoenix is only a single interface to your underlying Elixir application, and the web layer, by design, doesn't contain business logic, but rather just gives you a web-friendly way to talk to the application itself. The community has come up with the mantra of "Phoenix is not your application" to drive this point home.

This approach and separation of concerns also means that building e.g. REST or GraphQL APIs on top of your application is simple, as your web framework has no say in how the data is actually structured or queried.

</comment></comment></comment></comment><comment><USER15> Great work!

I wasn't able to find anything on deployment in the docs. What does it look like?

I've been looking for a framework with the following requirements:

      - Functional-ish language
      - Statically typed with Result<T, E> error handling.
      - Garbage collected.
      - Compile time checked HTML templates, with autoformatter  and IDE support (like working with JSX/TSX in VS Code).
      - Some kind of SQL DSL that has decent IDE support (like Ecto on Elixir, Diesel on Rust).

This framework checks off more of those than any framework I've seen. I'll definitely be giving it a try.

<comment><USER16> Deployment documentation is WIP at the moment and will be released soon. In the future we want to release a Cloud where the deployment will be as easy as clicking a button and having it online in a few seconds :)

</comment></comment><comment><USER17> Nix seems to be heading toward a critical mass in Germany. I use NixOS for my work computer, and couldn't imagine using any other OS. I keep a LinkedIn search open for nixos, and almost all of the hits are German. I'm interested in what kind of an organization might try out something like IHP? I've had a tough enough time introducing Typescript and more functionally oriented patterns in my team, so my guess is that organizations that would seriously consider IHP probably have a significantly different corporate culture.

</comment><comment><USER18> A Haskell project with docs, this is a pleasant surprise.

I've been playing around with Phoenix recently and I've been missing a decent type system (Dialyzer is pretty bad). I know very little Haskell but this makes me want to dip my toes in.

</comment><comment><USER6> First off, nice work!

I always thought it is better to mix client/server rendering; the 'everything client' or 'everything server' both do not work for a large number of applications. So why not mix them. Unfortunately not much out there battery- included that consistently supports that model.

I did not dive into IHP (I heard about it as the RoR for Haskell) but, after reading the introduction, I'm probably going to get depressed when I hear how you do the inevitable client-side stuff here; there is a really good opportunity to mix them as there is HSX and you can compile Haskell to JS. So there should be an opportunity to appoint, where supported, some (parts of) a page as serverside/clientside.

<comment><AUTHOR> Thanks for your feedback! :)

We have been tinkering a bit with building something close to Phoenix LiveView with HSX. Hope we can show something in that direction later this year.

<comment><USER6> That sounds good; thanks for the response. Most stuff I do is in the middle between static/dynamic; needs solid SEO and prerendered parts for various reasons but also contains, for browsers that support it, quite a lot of dynamic elements. Now we just use asp.net/static-with-some-react but that is driving me bonkers.

<comment><USER19> Static with some react sounds like a nightmare. One of the primary reasons why many moved to JS frameworks was to have a better separation of concerns and a single place where GUI logic resides.

May I suggest you have a look at Next.js. It lets you solve this in a very ergonomic way. Maybe even for your existing project.

<comment><USER6> Yeah it is a nightmare; it is not my choice. It is the same 'everyone uses it so we need as well' type of thing thrown in by partners.

Thanks for Next.js: I did not know it.

</comment></comment></comment></comment></comment><comment><USER20> Wow! Love it. I use my own hand rolled framework but will consider switching to this.

</comment><comment><USER21> I've just played about with this and love what I see so far. If anyone wants a small site set up and are willing to take a bet on this tech, let me know - I'd be happy to collaborate and see what this is like in prod :)

</comment><comment><USER22> Looks really cool!

I like the neat UI, auto refresh and everything. I even skimmed the 27-minute demo video (that's a bit long guys), but I don't see any reference to testing, making this a nonstarter for me.

<comment><AUTHOR> Hey, thanks for your feedback! :) We're internally using hspec for testing our code. We're going to add some more documentation on using hspec with IHP soon.

</comment></comment><comment><USER23> So as i see, this is like a Rails framework with static type checking. Best of both worlds !

I'd love to see a guide on integrating with webpack or any frontend tech in the stack.

</comment><comment><USER24> This sounds awesome! I'm using NixOS for almost a year now and am still very pleased with it. It can take some time to get things to work, but when it works you'll never have to look at it again! My biggest problem with Haskell is usually getting the dependencies right. So, the Nix package manager seems like a good fit.

</comment><comment><USER25> This looks interesting.

I like how your code generation seems to expose most of the structure for customization, but have you thought about having different customizable templates for code generation? Like generating just REST API for this table vs generating user visible views.

<comment><AUTHOR> This is something we plan to do in the future. We have been thinking about adding a plugin system, where the plugins can provide custom code generators to the dev environment :)

</comment></comment><comment> steve-chavez Using Nix to handle dependencies(haskell, pg) in a framework is really cool!

But would IHP work in Windows natively? AFAICT, Nix doesn't work in Windows unless you use WSL(and even here I'm not sure how smooth it is).

<comment><AUTHOR> Thanks for your feedback :) Running IHP with WSL works pretty well so far. Some of our closed-beta testers have been running IHP on windows. We even made a video to get people started easier on WSL: [https://www.youtube.com/watch?v=fM0WTMLdmVw](https://www.youtube.com/watch?v=fM0WTMLdmVw)

</comment></comment><comment><USER26> Seems very interesting, and a move in the right direction.

What's it like to debug when something goes wrong?

</comment><comment><USER27> Nitpick: Javascript is usually compiled.

</comment><comment><USER28> What's the difference with Elm?

<comment><USER29> Regarding execution, Elm is for client-side rendering, whilst this is for server-side rendering. As a language, they're very similar, one could even argue that Elm is a subset of Haskell :-)</comment></comment>


Latter-day Saints claims IP rights to block "Mormon" dating site  - <AUTHOR> http://arstechnica.com/tech-policy/2014/06/latter-day-saints-claim-ip-rights-to-block-mormon-dating-site/

<comment><USER2> Just rename the dating website MorMatch.

Problem solved, and it's a better name.</comment>


What's Next for Agricultural Drones? - <AUTHOR> https://www.precisionag.com/in-field-technologies/drones-uavs/whats-next-for-agricultural-drones/ <comment><AUTHOR> I've know several drone companies in the last twenty years that were waiting for BVLOS in order to work doing remote sensing work for farmers. Sadly they all went out of business while still waiting.

A Michigan company has failed for over a year trying to get a permit to test on a limited scale in a very rural area. It's all very frustrating waiting for government permission.</comment>


WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents - <AUTHOR> https://www.nytimes.com/2017/03/07/world/europe/wikileaks-cia-hacking.html?smid=tw-nytimes&smtyp=cur&_r=0 <comment><USER2> Main discussion at [https://news.ycombinator.com/item?id=13810015](https://news.ycombinator.com/item?id=13810015).

</comment><comment><USER3> This headline is extremely dangerous. The phone itself was owned. No encryption was harmed by capturing the keystrokes and audio before it reaches the application. NYTimes should be ashamed of themselves for basically lying about the nature of the hacks.

<comment><USER4> No, it's not.

The encryption is not broken, it's _bypassed_. The data go to an unintended third party, even when the encryption is legit, rendering the encryption useless.

So the word "bypass" is correct.

<comment><USER5> This is a dangerous headline because it implies that Signal was broken, which could lead to people moving to LESS SECURE SERVICES because they think the more secure one is broken. When in reality is the phone and OS.

They have similar end result for the phone in question, but headlines like this can lead to people being less secure on the whole.

<comment><USER6> Most users cannot tell the difference between between the Phone, OS, App and the signal (Let alone an app named Signal). Likely the journalists work with tech savvy to make sure their understood this and it was hard for them to make sense of gigabytes of technical jargon and noise.

Arguing this point at all is silly when many people, even many IT professionals don't know and don't care about the difference between bypassed and broken. This arguing detracts from the important news...

The CIA sees fit to ignore the security of Americans by not alerting the companies that make the software the CIA exploits. They do this to insure they can hack whoever they want, and there is no meaningful oversight and no ethical, economic or constitutional consideration.

<comment><USER7> That hardly matters if people's response is to use other, less secure things, as was the case with the Guardian and Whatsapp.

<comment><USER6> This is entirely a non-issue.

If group with the massive funding and pervasive reach like the CIA can operate with impunity it does not matter what app or what security you think you have.

<comment><USER7> Going from easy dragnet surveillance of unencrypted communications to having to use expensive to deploy, develop, maintain targeted attacks that get patched (with, on iOS, ridiculously high penetration rates) does not seem like a moot issue.

<comment><USER6> I don't see how this goes from one to the other. It seems that just about every Android and iOS device can be part of an "easy dragnet" without any app installed. If the wikileaks article is correct about the CIA having kept multiple 0-day exploits hidden for each OS, then breaking anything even remotely is a work ticket and not a research project for them.

The fine distinction of one app being singled out sucks, but it really is small potatoes here. The owner of the app should write the NYT and complain that their app was used inappropriately or perhaps write an editorial to get even more free advertising. The real news is that the CIA lied to Americans and the President so they could continue damaging American businesses, in the name of protecting America.

It sounds like we are not too far off from the CIA being able to write self spreading malware that allows monitoring they just haven't because... maybe it would be too easy to spot. Oh wait groups like the CIA did this already and rigged it to delete itself when not on one of their intended target's machines, stuxnet.

<comment><USER7> You made a specific claim: no app, easy dragnet, work ticket level, because tons of hidden 0days. I'm taking it as read that a publicly patched one doesn't count. Is there evidence for that claim in the actual documents?

Pending that, here is evidence of a counter claim. I'd repeat what tptacek said, but he's whittled it down better than I could: [https://news.ycombinator.com/item?id=13811541](https://news.ycombinator.com/item?id=13811541)

To cite Tony Arcieri, the only elite cryptanalysis trick in play here is "Android is a tire fire". Cue surprised gasp from security researchers.

Furthermore, you did not refute my central claim. Popping a Cisco 12k: read a bunch of unencrypted comms until detection. Target a specific person to get bit by a specific iOS exploit: maybe read some of the data until it gets patched. Surely you'll agree that one is drastically more expensive than the other?

<comment><USER6> I haven't gone through all the documents but the summary does say verbatim:

> dozens of "zero day" weaponized exploits against a wide range of U.S. and > European company products, include Apple's iPhone, Google's Android and > Microsoft's Windows

The only presumption on my part is that they are remotely exploitable, which is practically a requirement for mobile device exploits to be useful because physical access is hard to obtain. I do plan on going further through these, they look fun.

Of course encrypted communication is better for the user than unencrypted, but this is not the place for that, which is why I ignored it. This was supposed to be a discussion about massive government overreach, not petty squabbles between apps. With unfettered access to these phones there are all manner of hypothetical attacks that could go after any of these app providers and not just snoop on the communications of the users. With root access to a large number of phones and little oversight their capacity for harm is frightening, this seems more worthy of discussion.

<comment><USER7> The documents do not mention encrypted communications; that same summary editorialized them in.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> And people wonder why I am only lukewarm about encryption and opsec. I use both for myself, but I've given up evangelizing other people years ago because (as I've said here on HN many times):

For regular people, the effort of encrypting things is simply not worth it because they're powerless against a really determined attacker. It's rational to protect against casual attacks from spammers and scammers, but protecting oneself against state-level attackers is futile unless you make a full-time job out of it.

Someone usually pipes up at this point saying 'we need to limit the powers of the state', like some sternly-worded law is going to undo the existence of the technology or take away the vast economic and political incentives to deploy it. Get real folks, technology doesn't get un-invented, and powerful organizations are just like powerful organisms; they're opportunist, they maximize their own chances of survival, and when they do collapse the resulting power vacuum is filled as rapidly as any other vacuum would be. One can certainly seek to govern the behavior of a state or state organ, but attempting to limit its technical ability is naive, for the same reason that you'd be naive to try to fix police brutality by legislating about the design parameters of police batons.

</comment><comment><USER9> > WikiLeaks, which has sometimes been accused of recklessly leaking > information that could do harm

Nice passive voice there, NYT.

</comment><comment><USER10> We really need Qualcomm and others to _document_ their hardware interfaces for modems, baseboards, and SoCs so that open firmware and drivers can be developed for these devices.

<comment><USER6> While I completely and I think I understand why, could you expand on this? If I did I would probably not be as accurate as you.

</comment></comment><comment><USER11> This headline is false and misleading, and does not reflect the headline on the article (WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents)

<comment><USER12> The headline here was the headline in the article. They've changed it after the submission and I believe mods here are going to do the same.

<comment><USER2> Yes. NYT often changes their headlines and we follow suit, with some lag.

</comment></comment></comment><comment><USER13> You should consider the assumption that your security IS compromised at any given point in time (bypassed or whatever) then you could foresee and prevent some worst case scenarios which usually come from hubris nonetheless ("hey, our app is 100% secure and tested by the top security experts - not like other apps on the market").

<comment><USER14> This point can't be emphasized enough. Sophisticated operators always assume they're being listened to, and take precautionary steps.

</comment></comment><comment><USER15> > According to the statement from WikiLeaks, government hackers can penetrate > Android phones and collect "audio and message traffic before encryption is > applied."

This a perfectly useless bit of information in that it says nothing about how this penetration could occur. Pretty much anything can be cracked with a trojan. Something like a currently valid remove exploit would be a much bigger deal.

I could say that all the secure apps are broken because I can stand behind you and look over your shoulder while listening to anything you might say.

</comment><comment><USER16> To me this is much more worrying:

> As of October 2014 the CIA was also looking at infecting the vehicle control > systems used by modern cars and trucks. The purpose of such control is not > specified, but it would permit the CIA to engage in nearly undetectable > assassinations.

[https://wikileaks.org/ciav7p1/](https://wikileaks.org/ciav7p1/)

Given the fact that car makers don't even have "PC age" security in their cars, things are looking pretty bad for self-driving cars in general.

<comment><USER17> Makes the conspiracy theories regarding journalist Michael Hastings' death in 2013 seem more plausible. [1]

Former U.S. National Coordinator for Security, Infrastructure Protection, and Counter-terrorism Richard A. Clarke said that what is known about the crash is "consistent with a car cyber attack". He was quoted as saying "There is reason to believe that intelligence agencies for major powers — including the United States — know how to remotely seize control of a car. So if there were a cyber attack on [Hastings'] car — and I'm not saying there was, I think whoever did it would probably get away with it."[68]

Cenk Uygur, friend of Hastings' and host of The Young Turks, told KTLA that many of Michael's friends were concerned that he was "in a very agitated state", saying he was "incredibly tense" and worried that his material was being surveilled by the government. Friends believed that Michael's line of work led to a "paranoid state".[80] USA Today reported that in the days before his death, Hastings believed his car was being "tampered with" and that he was scared and wanted to leave town.[81]

[1] [https://en.wikipedia.org/wiki/Michael_Hastings_(journalist)](https://en.wikipedia.org/wiki/Michael_Hastings_\(journalist\))

<comment><USER18> His brother and family don't believe the conspiracy theories. If there was any evidence, I don't think they'd be scared to say so in such an emotional state.

Also in the police report, I believe his brother said he had been using DMT and he tested positive for what was likely Adderall. He was in a unique state to truly be paranoid and throwing psychedelics in the mix could cause one to try to cope in ways that challenge reality.

Of course, this also would be the perfect time to stage a murder and it's not improbable that someone did discuss killing him. Also DMT only last 5-10 minutes, he certainly wasn't driving while doing it and if anything, it can give you a sense of peace and acceptance to the craziness of life.

<comment><USER17> I think given what we knew until today, it was prudent for his family to deny the theories. Now that we have evidence showing car hacking isn't just some theoretical exploit, but something they were actively looking into around that time, it merits reexamination.

</comment></comment></comment></comment><comment><USER19>
      According to the statement from WikiLeaks, government
      hackers can penetrate Android phones and collect
      "audio and message traffic before encryption is applied."

How is that possible? Isn't the data encrypted before it's sent over the wire?

<comment><USER20> The kernel is owned (or some part of the phone below the application level). The encryption only gets applied at the application level before the messages are sent down the wire.

The interception happens _prior to the encryption being applied_. Think of it as a dongle on the wire between your keyboard and the computer. It doens't matter if the computer is secure - the message is intercepted prior to any encryption.

This is, what I am assuming, has happened here.

Edit: lots of stuff deleted for very valid criticism, as below.

<comment><USER21> > Given Google's stance of not encrypting local storage in any way that I am > aware of, this is fundamentally unsurprising. I have long been saying that > Android is insecure and that storing passwords in Chrome is dangerous.

ChromeOS and Android both implement FDE. There are some legitimate criticisms of (especially) the latter, voiced by e.g. Matthew Green, but you're just speaking nonsense here.

There's very little value in per-app encryption on desktop OSes; it's security theater.

I shudder to think of what your "secure communications" app does. I hope you're a good lawyer. ;)

<comment><USER20> I am not talking about ChromeOS - I am talking about the Chrome browser. Localstorage, last I checked, which was recently, is plaintext.

> ChromeOS and Android both implement FDE

Which is irrelevant if the runtime is compromised, which appears to be the case.

<comment><USER21> Let's be all Socratic here:

Given a desktop OS like Windows that implements FDE like Bitlocker and runs a browser like Chrome, can you describe a hypothetical threat in which Chrome encrypting localstorage would prevent exploitation?

<comment><USER20> Yes - worms or browsers that scan local data files without accessing the runtime of the parent application.

<comment><USER21> So your threat model is "malware which has access to memory containing plaintext but is written by idiots"?

0_o

<comment><USER20> Dunno if you are still checking this thread, but I had a followup to this question.

It seems to me that certain cryptoviruses function in the following way (e.g. certain variants of ransom_vxlock - I will see if I can find a specific example):

* The virus functions like other cryptoviruses, encrypting local data and holding it for ransom

* However, in addition to holding your local data ransom, it archives certain files that are likely to hold passwords (e.g., the chrome password store), and then emails them to the C&C server

If this is the case, would local encryption of the chrome password store be a protection, or would the decryption of this store be trivial the the virus author? Again, assuming that the virus author is a script kiddy.

So, basically, I am asking that if the characterization of the virus described is accurate, doesn't that mean that the threat model I describe also actually occurs in the wild? I'm not trying to be facetious here - I am trying to get to the bottom of this.

I will try to find links to support the above.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Edit: deleted, for very valid criticism. Next time I won't post in a rush during work hours.

<comment><USER21> Don't take this the wrong way, but as a non-lawyer, I try to heavily caveat any statement I make about the law.

Would you consider heavily caveating statements you make about information security? A lot of what you say here is basically wrong.

<comment><USER20> > I try to heavily caveat any statement I make about the law.

That is appreciated, and you are in the minority.

I'm taking this advice, btw, and being more circumspect when I post in the future.

<comment><USER21> :)

Cheers.

<comment><USER20> For serious, thank you for taking the time to engage. I do take this seriously.

<comment><USER21> Yep. Same. And I would probably have posted a longer and less confrontational explanation of why you're (mostly) wrong if I weren't tired after a long day of work. ;)

The whole "why not encrypt local resources" thing is an odd red herring that a lot of (even fairly experienced) people trip over. There was a massive public furor over Chrome's chrome://settings/passwords (i.e. lack of a master password) design choice a couple of years ago that was a specific such case in point.

<comment><USER20> This argument is almost exactly what I was on about. I'd love to see some summary of it and why they came down where they did.

<comment><USER21> Sorry. I went to bed. I'll frame the basic argument for Chrome and then show how it expands to other systems.

Chrome: </comment></comment></comment></comment></comment></comment></comment></comment><comment>=

Someone who can access chrome://settings/password is presumed to have physical access to your powered-on, unlocked machine. E.g. someone who sits at your keyboard when you get up for coffee.

And that person can just as easily install a Chrome extension that sniffs your passwords or steal your raw auth cookies directly from the developer console. (He could even paste some JS into the developer console to intercept the password as-typed by autocomplete!)

(Note that an attacker with access to a locked/powered-off machine or with no local access is not part of the threat model, since they are presumed to be addressed by FDE, screen locks, remote access controls, etc.)

Now, the major counterargument is essentially that a lot of unsophisticated attackers (like spouses) may not know about cookie jars or JavaScript, but they know about "view saved passwords." I find this argument somewhat reasonable, but from some vantage point it's security theater--not knowing about ctrl+j isn't a strong security guarantee, after all. So I view the Chrome team's stance as being a very principled one, namely: don't invest in "security" features where a bypass would not be a bug.

(In some literature this is referred to as a "security boundary", typically defined as "a control which, if bypassed, has a bug." Note the contrast with, for example, spam filters and antivirus, which may be sometimes bypassed while working as intended.)

More generally: </comment><comment></comment><comment>===

I think what was lacking in this conversation in general was a firmly defined threat model and a firmly defined security boundary. My contention about per- application encryption is that it doesn't represent a security boundary because any attacker who can execute code that can read application-ACL'ed data on disk is by definition either running code at a higher security level (e.g. has root) or is running code at the same security level (and can thus inject code into the browser process itself).

This conversation gets a little more complex when talking about mobile OSes that have per-application sandboxing, but the same observation effectively holds.

Anyway, I'm tired of typing, but hopefully that makes a bit of sense. Let me know if I'm being confusing.

<comment><USER20> So, tell me what I am misunderstanding here:

* On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database [https://www.howtogeek.com/70146/how-secure-are-your-saved-ch...](https://www.howtogeek.com/70146/how-secure-are-your-saved-chrome-browser-passwords/), which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has user-level permissions can access the Chrome passwords? Because Chrome is not available through the app store, it does not store passwords on the OSX keychain, which, again, correct me if I'm mistaken, requires higher permissions to read? So that, for instance, a malicious script that only had user-level permissions could not access the contents of databases encrypted with credentials stored in the keychain?

<comment><USER22> If the malicious script can execute arbitrary code as you then you're owned, essentially you always allow unsupervised use of your computer which as discussed is not part of the threat model.

<comment><USER21> To expand on this (correct answer) very slightly, what you say (libertymcateer) is true but misses the other vector:

A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any other process at the same or lower security level; in OSX, at a quick Google, it looks to me like [http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_c...](http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_create_running.html) may do the same.

So the attack that this opens up is to basically wait until Safari is running and loads the credentials into its memory--which it has to do to prefill the password field in a page--and then just read that memory from your code running in the same process in a different thread (which shares the address space). And if you don't want to wait, you can simply request the credentials directly from the Keychain API; Keychain doesn't know you're not "Safari" (since you're running in the same process) and will happily give you the credentials!

Now, there's still a small advantage to the DPAPI/Keychain approach, namely that it allows the OS to show approvals to the user ("Unlock the keychain?" dialogs or whatever), ensuring that the malware can only steal credentials while the user is present. There are some circumstances where a credential API is nonetheless useful. Offhand:

1\. Cases where there's a test-of-presence ("Do you want to unlock the Keychain?") conducted by the higher-privilege process, and where approval is not routine (so that the user is not going to just click "OK"). Browser password autofill is not such a case, however.

2\. Cases where there's a test-of-presence and the user assent is transactional (i.e. they see what they're approving and the approval is only good for that one action--as with Windows UAC).

3\. Cases where the credential granted is a signature and not a bearer-token, and we find some advantage in the token itself being bound to the device. (IOW, the down-level process can steal a signature, but it can only use the signature for some limited use, and cannot steal the signing secrets, which never leave the privileged domain.)

So to get this right requires a lot of thought about things like broker processes, transactional approval, etc. I'm far from an expert in this, but hopefully the above makes some sense.

<comment><USER20> Right - you are describing a very well written worm up at the top of your comment.

However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on this.

In other words, what I am saying is that you are describing a very nasty theoretical worm - I am, however, describing to you a family of worms that is currently out in the wild and causing a hell of a lot of damage, and, as far as I know, actually does function in the way I describe. Filecryptor viruses can be made / purchased by any script kiddy jerk these days, and it seems to me that they do not function in this very sophisticated way you describe, but instead _may actually be stymied by local encryption_ of files with passwords in them. (Or, rather, the distribution of your passwords to the virus owner would be stymied.)

I would very much like to know if is accurate or not. I understand that the devil is in the details, but if it is true, then I stand by my point that it seems unwise (borderline indefensible) not to encrypt local password stores - as there is a known valid threat. If it is not true, then I stand corrected - which happens all the time.

Either way, I am deeply interested to know.

<comment><USER21> I don't have a huge amount of exposure to current malware trends, to be honest --it's not the area I work in at the moment. So tl;dr I can only guess.

You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"\--they're refusing to implement an ambiguously useful security feature because its bypass would not represent a bug.

Whether such a feature is nonetheless valuable for the user is unanswered by that discussion, however; as you say, it may have value in some circumstances.

However, remember that by volume most exploitation is (as best as I can tell) economic--people who do it for business. And people doing it for business can buy whatever malware is on the market. If stealing in-memory secrets is reliably accomplished (which it is), malware vendors have a strong incentive to implement this and sell it as well.

So I think you have the right idea, but answering the question is nontrivial. If Chrome implemented file encryption (or, more likely, used the platform APIs where available), would the engineering cost (and complexity--e.g. different behavior on different platforms) be counterbalanced by the increased cost imposed on malware authors? Or would one or two malware authors quickly adapt and malware prices/effectiveness would remain fairly static?

You get the point.

<comment><USER20> Found it: the worm is called Dynacrypt.

Check it out and let me know what you think.

Edit: from the top google result on Dynacrypt:

>While the ransomware portion of DynA-Crypt, as described in the next section, is a pain, the real problem is the amount of data and information this program steals from a computer. While running, DynA-Crypt will take screenshots of your active desktop, record system sounds from your computer, log commands you type on the keyboard, and steal data from numerous installed programs.

>The programs and data that DynACrypt steals includes:

>Screenshots

>Skype

>Steam

> _Chrome_

>Thunderbird

>Minecraft

>TeamSpeak

>Firefox

>Recordings of system audio

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> CIA Android Exploits

[https://wikileaks.org/ciav7p1/cms/page_11629096.html](https://wikileaks.org/ciav7p1/cms/page_11629096.html)

As you can see they pretty much all reference very old versions of Android (v4) and Chrome.

</comment><comment><USER24> I thought they were already compromised since both these services use SMS authentication; since the defaults AFAIK aren't particularly concerned about a change in the public key, it's broken for anything secure anyway.

Tox on the other hand seems much more secure... though I guess if you're phone is compromised you're pretty much screwed to start with (which is not too hard with all the bloatware one needs these days).

<comment><USER12> See this: [https://github.com/TokTok/c-toxcore/issues/426](https://github.com/TokTok/c-toxcore/issues/426)

Long story short: if someone obtains your Tox private key, they are able to impersonate you in the conversations with other people without you realizing it.

Tox developers admitted this was an issue. Fixing this means changing the protocol itself (which will affect everyone).

Tox is still experimental (which they admit here: [https://github.com/TokTok/c-toxcore/issues/426](https://github.com/TokTok/c-toxcore/issues/426)) and it is not advisable to use it.

</comment></comment><comment><USER25> Given the other revelations of the last few weeks, I have to wonder if these exploits are getting installed on every phone that the CBP demands people unlock. Seems like the obvious thing to do. Best not to trust your phone or any software on it at least without a factory reset, and preferably a software update, after it's been in CBP custody for any time.

</comment><comment><USER26> Besides the initial titlegore, these tools really aren't that surprising. I've always operated under the assumption that if the NSA, CIA, etc are in your threat model you've already lost.

</comment><comment><USER27> Lol at NYT, it says that when jack into an android phone they are able to route the messages to a third party before it gets encrypted

</comment><comment><USER28> This is why we should not rely on encrypted apps running on top of some other platform.

disclosure: working on an open source alternative for messaging

<comment><USER29> Wouldn't you also need an encrypted os for your phone?

<comment><USER28> A fully open source RTOS that is trusted and only running this single application. The only external communication is the encrypted messages.

</comment></comment></comment><comment><USER30> This just in: man looking over your shoulder bypasses strongest Signal encryption!

</comment><comment><USER31> I found none of these revelations surprising. In this era, you have to assume that someone is monitoring you. You're naive if you think otherwise.</comment>


Ownership in Rust: It's not my problem - <AUTHOR> https://medium.com/@thomascountz/ownership-in-rust-part-1-112036b1126b <comment><USER2> Some of the inaccuracies of this article are being discussed here: [https://users.rust-lang.org/t/the-copy-trait-what-does-it- ac...](https://users.rust-lang.org/t/the-copy-trait-what-does-it-actually- copy/18730)</comment>


Ask HN: Windows Laptops with Good Keyboards? - <AUTHOR> My 2018 Macbook's butterfly keyboard started causing issues 4 months after I bought it. Apple will replace it but it's clear this problem will happen again.
So I've decided to move back to Windows. Linux isn't an option because some tools I use are Windows/Mac only
What are some good Windows laptops currently on the market with good keyboards? Writing is a big part of my work so a solid keyboard is a must.
I see some Thinkpads on Amazon for $600 right now, which is honestly too cheap for a Thinkpad. I've also been burned by Lenovo in the past. Is a Thinkpad still a good option then? <comment><USER2> I would suggest waiting for Icelake laptops. Recent Twitter thread from someone asking for a similar suggestion.

[https://mobile.twitter.com/lemire/status/1156025690619146240](https://mobile.twitter.com/lemire/status/1156025690619146240)

[https://mobile.twitter.com/Wunkolo/status/115949643138157363...](https://mobile.twitter.com/Wunkolo/status/1159496431381573632)

[https://www.reddit.com/r/hardware/comments/cnmail/10nm_ice_l...](https://www.reddit.com/r/hardware/comments/cnmail/10nm_ice_lake_based_dell_xps_13_inch_7390_2in1/)

</comment><comment><USER3> You can't go wrong with any of the thicker Thinkpads like the P series(I personally use a P50 now), but that does come with lesser portability. With the thin and light models like the X1 Carbon, there's probably some level of compromise to get the laptops that thin, but I'm sure it's still miles ahead your current Macbook's keyboard.

Other notable mentions: LG Gram, XPS (2018/2019 models)

</comment><comment><USER4> Asus Zenbook / Thinkpads (although personally I don't like its "raw/oldschool" design) / Surface Book (2)

</comment><comment><USER5> Huawei's matebooks are nice

<comment><AUTHOR> They look nice but are they long term reliable?

<comment><USER6> I have a matebook X pro running Linux (with its own limitations under Linux) for a year now and without any issue. Battery is excellent, keyboard and screen are fantastic as well.

</comment></comment></comment><comment><USER7> Msft Surface Book 2

MSI GT 76</comment>


MG Siegler Will Become Our Apple Columnist, And Join CrunchFund As A VC - <AUTHOR> http://techcrunch.com/2011/10/03/mg-siegler-will-become-our-apple-columnist-and-join-crunchfund-as-a-vc/ <comment><USER2> At least now he's finally getting the official label for what he's always been: an Apple columnist.

<comment><USER3> Apple columnist seems generous to me. Apple evangelist/advocate seems a lot closer to what he does. He forms what I consider the trifecta of Apple evangelists online: MG, Gruber, Dilger.

<comment><USER4> I'd throw in Horace Dediu of Asymco and Marco Arment and maybe David Pogue. I don't know who Dilger is.

<comment><USER3> You don't know Dilger? Consider yourself lucky -- until now:

<http://www.roughlydrafted.com/>

<comment><USER5> He also write the more partisan "news" items at appleinsider.com. Even the people who register on a site called Apple Insider seem to think he's a bit _out-there_.

</comment></comment></comment></comment></comment><comment><USER4> My opinion on MG Siegler cemented after the last fight he had with Dan Lyons. I don't even really like Dan Lyons that much (though I was pretty amused by Fake Steve Jobs). But this post: [http://realdanlyons.com/blog/2011/09/28/kindle-fire-and- the-...](http://realdanlyons.com/blog/2011/09/28/kindle-fire-and-the-tricky- business-of-chasing-scoops/) seemed fair, reasonable, not hostile, and even careful in giving credit where it was due. And it had a great point: that we'll know when we know, and that the value of this type of "scoop" is close to zero.

Siegler's response was a fairly vicious, direct ad hominem with no greater point. [http://parislemon.com/post/10774472888/fake-steve-jobs- funny...](http://parislemon.com/post/10774472888/fake-steve-jobs-funny-real- dan-lyons-sloppy-lazy)

Judge for yourself. I did, and I've decided not to read his writing anymore.

<comment><USER6> I don't think very highly of either although both can commit journalism occasionally. Dan Lyons was an SCO shill for years. MG Siegler's writing style can best be described as a borderline parody of tech journalism meets pro wrestling.

</comment></comment><comment><USER7> MG's writing is barely passable for a professional, his knowledge about business and finance is lacking, and the subject matter he writes about is generally...Apple.

Granted, he does produce a moderately insightful piece every now and then, but to me, the fact that he's being recruited by old school media is telling; more bad business decisions from people who don't "get it". Personally, I don't get the appeal.

</comment><comment><USER8> I love MGs writing and from what I know of him (admittedly just online through TechCrunch), he seems like a cool guy.

But I'm failing to see how being a (great) writer translates into being a VC?

<comment><USER9> yeah agreed, in fact I'd say it's the wrong type of person for the job.

a writer on techcrunch tends to cover hype products with no real value

a VC on the other hand invests money into products that have to make money

<comment><USER10> Being a good investor is basically about "deal flow" and good judgment. Seems like writing for the tech press gives you lots of practice at both.

<comment><USER9> yes, but all of that is brought to the table by Arrington

<comment><USER11> MG has been a successful Arrington employee/teammate for years, so...

Jessica never sold a startup, but seems to do fine on a VC team.

</comment></comment></comment></comment></comment><comment><USER12> From the outside looking in, it sure seems like TechCrunch is doing this so he sticks around long-term. 2/3 of their most popular writers are gone and they desperately want to hold on to him as TechCrunch moves into the arrington-less era.

</comment><comment><USER10> This is unfortunate. The rush-to-publish tech blogging format strips away almost personality -- it's just incredibly hard to be fast enough and keep anything.

MG was one of a very few writers who could handle the pace and maintain a distinctive voice. I hope he's a great investor, but if it means less public writing, the industry will be poorer for it.

</comment><comment><USER13> Both, but only as a limited columnist at TechCrunch.

[http://techcrunch.com/2011/10/03/mg-siegler-will-become- our-...](http://techcrunch.com/2011/10/03/mg-siegler-will-become-our-apple- columnist-and-join-crunchfund-as-a-vc/)

</comment><comment><USER14> So who is really left thats a great writer, MG and Micheal were my favorite posts.

<comment><USER15> To be fair, I really, really enjoy a number of the guest posters on TechCrunch - I find the third-party columns to be refreshing and informative. Tom Anderson, Justin Kan, etc...

But you're right, it will be interesting to see what happens to TechCrunch now without MG in a regular contributing position. With Arrington and Paul Carr gone, most of TechCrunch's editorial "stars" have moved on.

</comment></comment><comment><USER16> The one who didn't flame out?

</comment><comment><USER17> So MG got to follow Arrington _and_ still write for Techcrunch? Talk about exit strategy and lesson in keeping your bridges intact.

Also nice to know that he'll finally be labeled for what he really is, an Apple fanboi.</comment>


Ask HN: Customer wants to acquire us before launch - <AUTHOR> Hi everyone,
We have been building a product for the construction industry for the past 2 months. We have reached out to potential customers.
In our initial sales pitch, we presented an option where we would build them the solution iteratively - they would get value, month to month. But for some reason, discussion escalated - they want some ownership. We haven't even finished building the product completely yet.
Sales are no go, they are insisting on ownership - and want to hire me, and cofounder. Everything is very mirky. Finding Hard to decipher. They also want exclusivity on the product, if they purchase it.
We are bootstrapped so far. We haven't even though of doing a seed round or making a pitch deck.
Any advice on how to approach this?
It's important for us to have first client who is very interested, as we can use their workflow and past work to assess and build the product. <comment><USER2> Why did you start your company? I'm imagining it's not to work for someone else. If so, tell them "thanks, but no thanks"

Perhaps when they see their competitors will be the ones using it first, they will change their tune.

Also, get a good lawyer w.r.t. this company and anything you sign with them.

</comment><comment><USER3> I suppose there's a price at which you'd be fine walking away with for two months work? If their offer is below that magical number, you could instead offer them to invest in a seed round or offer advisor shares.</comment>