How do you use 1Gbps Internet links? Chattanooga residents find out - <AUTHOR> http://arstechnica.com/tech-policy/news/2011/04/how-chattanooga-uses-1gbps-internet-connections.ars <comment><USER2> $350 a month for an unmetered 1 gbps connection? That is cheaper than you can get it at a colo. Anyone want to get an apartment there with me and split the cost? Contact in profile. Nooga Apartment Colo servers :)

<comment><USER3> That's literally 10 times what a similar service costs in Hong Kong. Tokyo also has a gbps offering for about 60USD/month.

I really don't understand why this keeps getting submitted to HN. Yes, it's a good connection, but it's nothing amazing and it's ridiculously expensive.

<comment><USER4> In North America it's a big deal. Smaller, denser areas [Japanese cities] make it easier to afford rolling out networks. Younger infrastructures [the Nordic countries with 100Mbit to each home, IIRC] took the opportunity to roll out a more advanced infrastructure when they could. Here in NA, the incumbents are perfectly happy charging us for slower speeds over cable or ancient twisted pairs, with no need to invest in new infrastructure.

<comment><USER5> You can't use the population density argument when places like New York and Chicago have the same options as rural Iowa.

<comment><USER6> You'll find that US broadband/technology/cell-network/healthcare/alt-energy apologists trot out every excuse and make pretzel-twisting arguments for other first world countries having arguably superior things than we do. Some of the arguments are valid (we're a really geographically big country), but some are specious.

My favorite is "because such-and-such place has a monoculture while we are a melting pot". Huh? How in God's name would _that_ prevent us from getting high speed rail or gigE internet? So, because people have different colors and beliefs, we can't get broadband coast to coast? That just doesn't make any sense.

Another is the "our government is corrupt/monopolistic/fascist/corporatist/name-your-own-damning-description". So, if there's corruption, there must be _somewhere_ we can ram through gigE speeds through back-alley deals and nepotistic dealings like (supposedly) Hong Kong.

</comment></comment></comment></comment></comment><comment><USER7> Observation: For coworking and hacker spaces, apparently it reduces latency but that's about it for a business-class connection. Surprisingly, the issues of abuse tend to go away as multi-TB hard drives are self-limiting.

Potential Uses:

1\. Adaptive media streaming protocols that minimize frame skipping and buffering, and instead gradually reduces quality seem obvious.

2\. Outbound streaming to mobile perhaps.

Questions:

1\. What is the oversubscription of the various upstream connection(s)? In other countries other than the US, this is a required bit of disclosure.

2\. Which port(s) are blocked?

3\. What's the bandwidth, ping and packet-loss like?

<comment><USER8> My Internet connection at home and at work comes from EPB Fiber.

1\. oversubscription. I have no idea, honestly, but I do not have any problem maxing out my connection. I have the slowest they sell (30Mb). That is data throughput not bits over the wire so my actual connection is closer to 40 according to my network card. I can usually pull down 3.2MB/s.

2\. As far as I can tell only outgoing 25 (to other than their server) is blocked. Incoming 25 works fine.

3\. I kinda answered that above. I went to Alexa and tracerouted the top 10 Internet sites (that responded) from my Comcast connection before the install and then EPB right after. Comcast average: 14.5 hops 92.397 ms EPB average: 13.5 hops 37.891 ms

Hope that helps.

<comment><USER9> Could you run tests on speedtest.net and pingtest.net out of curiosity?

</comment></comment></comment><comment><USER10> Symmetrical downlink and uplink is the really exciting part to me. Imagine being able to transmit GB-sized files point to point in a matter of minutes. There are so many opportunities for stuff you can do with that :)

<comment><USER11> No opportunities while Comcast, et al. impose caps.

</comment></comment><comment><USER12> Article doesn't really answer the question: how _do_ you use a 1Gb/s internet link? My crappy Comcast connection can stream full-screen HD video from Netflix, and what more could a consumer reasonably want?

<comment><USER13> Obvious next step is 3D HD.

Also Onlive. Also more than one TV at the same time?

Live streaming HD video cameras from inside the house to outside when you're at work?

<comment><USER14> 3D video telephony.

</comment></comment></comment><comment><USER15> In the Netherlands optic fiber is being rolled out by independent companies, who then rent it out to internet providers. The way they decide where to do it is quite smart: you can vote for your own city, and if it gets enough votes, they'll provide it to the whole city. This way they can make sure they don't spend their money on a city where nobody wants it (yet).

</comment><comment><USER16> _"Those who have ordered face challenges; if they want to experience the full 1Gbps speed they're paying for, standard WiFi connections aren't fast enough. Some customers have switched to wired gigabit routers in order to access their full bandwidth."_

Facing challenges? Really? Of the handful of people to order the service, some of them didn't realise they would need more than a 10/100 router to use it? That's idiocy, either on the part of a technical user who didn't think of it, or on the part of the ISP who didn't explain it to a non-technical customer purchasing the service. It's not a challenge.

<comment><USER17> Honestly, my guess is they will be disappointed by how little difference there is between a 100mbit internet connection and a 1gbit connection in practice.

And, yes, setting up a gigabit wireless network counts as a challenge, even for non-idiots.

<comment><USER16> Wireless, sure, wired, not so much.

Disappointed because they would be thinking "wow facebook will load so much faster now"? Presumably they wouldn't be disappointed if their reason for upgrading is, say, for torrents or another type of filesharing, etc.

<comment><USER18> Maybe you missed it, but that's what the article mentioned. Wireless wasn't fast enough ("standard WiFi connections aren't fast enough"), so they switched to wired networks. It wasn't that they didn't know they would need a gigabit router, it's that they saturated the wireless network and upgraded to a faster wired network.

<comment><USER16> That's still the same issue. The router I have here at home isn't capable of handling a gig of traffic, wired or wireless. If my ISP sold me a gig connection, I would expect them to realise that, most likely my router won't support it, and to explain that to me (and, more likely than not, try to sell me a new router themselves).

It doesn't matter that they went from wireless to wired - even when moving to wired, the issue was still that they hadn't realised they would need a new router.

<comment><USER18> I guess we're reading it differently. I read it as "before getting gigabit internet I had a wireless router that worked fine, but after I had to use a wired router to get the new faster speed I'm paying for." I don't think they went through multiple wired routers because they were unable to realize that 100 != 1000 (regardless, many new wireless routers are also gigabit ethernet routers).

<comment><USER16> I read it same as you, but to me needing a new router isn't "a challenge", it's an obvious requirement that you know about before deciding to upgrade your connection. Same as needing to own some sort of networked device such as a computer in order to use any internet connection.

<comment><USER18> It might not be a new router. My wireless routers at home and work both support gigabit ethernet. But it could be a challenge to have to run wire and what not. I think it makes complete sense.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Some applications that might be able to make use of that kind of bandwidth... You could do a lot of high-fidelity virtualization with HD Video editing, image editing, even 3D modeling.

Telepresence is an obvious application.

Oh gosh, if you combined this kind of bandwidth with a bunch of Kinect sensors, things could get REAL. :-D

</comment><comment><USER20> The hidden cost is having a switch/router/both to handle the rates, as well as using Gig-rated cabling which is surprisingly not the same as 100Mb. When I hand crimped a number of cables and tested they weren't suitable for Gig.

Full Disclosure: I'm a shitty crimper.

</comment><comment><USER21> Can anyone point me to a howto? I'd love to spearhead something like this for my small community.

<comment><USER4> AFAICT, from a number of attempts I've read about in many communities:

1\. Get the tech people together

2\. Have a sensible plan to roll it out, backed by a utility or municipal government (so that they can levy a charge on all residents for initial costs), supported by your community, and with all due diligence done and paid for

3\. Get your pants sued off by whoever is currently providing high-speed

[edit: formatting]

</comment></comment><comment><USER22> Meanwhile, Comcast has no plans to run fiber to homes.

<https://twitter.com/#!/ComcastBill/status/45843247490273280>

<comment><USER17> It kinda seems like they've slowed deployment of high-bandwidth cable connections. I've got a 50mbit comcast business account now, but I've been promised that 100mbit will be available "soon" for quite a while now.

<comment><USER22> But by the time 100Mbit rolls out Google will have continued to roll out their 1Gbps fiber connections to rural areas. Not to mention Comcast's 100Mbit connection only has 10Mbps of upload speed. Comcast is slipping more and more behind every day.

<comment><USER23> The 100Mbit connection has only 10Mbit uplink? My 50Mbit Comcast connection has 15Mbit up. How disappointing that they would _reduce_ the more important half of the service on the "higher" tier.

<comment><USER17> Really? Mine is definitely 50mbit/10mbit. Maybe it varies by location?

<comment><USER23> Unless they changed it and I wasn't paying attention, it's 15Mbit/s uplink in the Salt Lake City area. The only reason I'm paying for 50Mbit/s down is so I can get 15 up.</comment></comment></comment></comment></comment></comment>


Ask HN: Easiest useable software you ever programmed for a client? - <AUTHOR>

I once had to create a simple membership application.
What it contained?
- Table {members [name:string, active:boolean]}{event [On:date]} and a junction table.
Members could be subscribed for an event and there was a report with a date range to check who participated.
Layout wasn't important, i used a simple bootstrap layout and the report was auto generated with a PDF generator class in Asp.Net MVC. (just give it some data and it generates the report without any special layout) <comment><USER3> The easiest (in terms of solution, but it took me a while to think of it) - <USER2> had maybe 30 modems on that had to terminate on a single server - we stuffed it with RS232 cards, the problem was that Windows Server came with only 5 incoming licenses on terminal services, and we had to connect everything on the other side to the inside network. And it was expensive (this was 2004), so I had to find a way to do it on XP. The solution - just install vmware player with linux, pass the com ports to the linux virtual machine and use the nat that it provides. We could connect as much as needed for the price of single XP licence. (we could not use straight linux box due to "REASONS")</comment>


Azure price cuts, now with node.js and MongoDB - <AUTHOR> http://arstechnica.com/microsoft/news/2011/12/azure-price-cuts-bigger-databases-now-with-nodejs-and-mongodb-support-hadoop-on-its-way.ars

<comment><USER2> Hmm, according to this page:

<http://www.windowsazure.com/en-us/pricing/calculator/>

The cheapest server (compute+database) is $100/month.

That can't be right, surely? Is there really no intermediate pricing? What am I missing?

<comment><USER3> Azure's pricing seem optimized either for medium to big sites (who need more than 2 front-end servers, hence would benefit from the per-hour pricing) or for agencies that will host multiple sites on the same server. Also, Azure is more "managed" than AWS or Linode. That is, you just write your application code and push it to the servers. There's no sysadmin work to do, nothing to install and configure but your own code.

</comment></comment><comment><USER4> Would love to see RavenDB <http://ravendb.net/> supported in the same way as MongoDB.

<comment><USER5> When mongodb is open source, hence free, I don't see a reason why they would add ravendb.

</comment></comment><comment><USER6> Now give me PostgreSQL and redis and I'm going to use this.

<comment><USER7> Given the developer/community response to the redis windows patch a few days back, I am not sure that would ever make it on to the windows platform (at least in its canonical form).

<comment><USER8> I don't want a merge, but at the same time I and people inside VMware used some time in the latest days to figure how a good win32 port could be feasible... so I think the biggest limit so far is that there are not enough efforts on the win32 port to make it viable, and not me or the community ;)

</comment></comment></comment><comment><USER9> The SQL Federation feature is pretty awesome. Is there anyone else offering a managed RDBMS with built in sharding capabilities?

</comment><comment><USER10> Good news. More competition is always welcomed. Hopefully this put pricing pressure on other cloud vendors.

<comment><USER11> I don't see any of my sites moving there until they start offering Linux nodes, which will, in all certainty, never happen.

How does it deal with autoscaling? If, for some reason, some property goes viral and starts to get too much traffic, what will it do?

<comment><USER12> > until they start offering Linux nodes, which will, in all certainty, never > happen.

I wouldn't be too sure - it is a serious gap in their offering, and MS can be pragmatic if it's to their advantage.

> How does it deal with autoscaling?

It doesn't, you've to do it yourself. What they do is make it (relatively) easy to spin-up new instances. There are also tools/frameworks that automate some of the tasks.

<comment><USER11> > MS can be pragmatic if it's to their advantage.

That's one point. I can't imagine any circumstance in which this would be advantageous to them.

> What they do is make it (relatively) easy to spin-up new instances.

Cool. Sometimes you are gifted with an application that will only run on Windows and nothing else.

When life gives you lemons, get salt and tequila.</comment></comment></comment></comment>


iMac Pro's T2 chip - <AUTHOR> https://www.macworld.com/article/3245764/macs/the-t2-chip-makes-the-imac-pro-the-start-of-a-mac-revolution.html <comment><USER2> I know I trust Apple[1] and all that but I (tin-foil hats on) don't like the system on a system stuff going on. I don't like closed systems that I have no oversight into, into what they might be logging, etc. The industry will likely follow Apple here and it's not too much of an issue given how low volume that iMac Pro is going to be but this could trickle down into macbooks and that'd be sketchy. I should just go hide in my bunker and build linux from scratch on a fully GNU open laptop -- alas that's not practical.

[1] more so than Google because Google uses my data and habits to sell me ads and sell that data to their customers, Apple wants to sell me gadgets and songs and movies, if that changes I'll drop Apple

<comment><USER3> I agree with you entirely, except in the case of Apple. I don't like closed systems either, especially when it comes to security, but, for some reason, I trust that when Apple closes a system, it's for security reasons. Their history with the Secure Enclave on iOS devices has given me a track record of security that I trust and, although it's still a closed system, the fact that they release white papers on every secure system gives me far more confidence than closed systems distributed by other companies.

I won't trust the industry when this becomes the norm but, until Apple does something to violate my trust, they've made it a point to earn trust when it comes to privacy and security.

<comment><USER4> I think Apple uses 'security reasons' as a cover to advance their monopolistic business models, in a way to keep their platforms locked down, and a way to extract a minimum 30% transaction osst and yearly fee for access to their walled gardens.

<comment><USER5> _monopolistic business models_

Apple are far from a monopoly, they don't even have a majority of the phone market, their PC share is still in single digits.

<comment><USER6> Monopoly isn't defined by share of whatever market description you find convenient, it's defined by pricing power: whether the seller can raise prices over some range without losing sales to competitors. There's lots of times when things in what intuitively descriptively are the same market by some product description are different markets in practice because people don't, in practice, substitute between them in response to price movement.

<comment><USER5> From Wikipedia:

A monopoly (from Greek μόνος mónos ["alone" or "single"] and πωλεῖν pōleîn ["to sell"]) exists when a specific person or enterprise is the only supplier of a particular commodity.

</comment></comment></comment></comment></comment></comment><comment><USER7> if youd like to cut past the fanboy fluff... [https://en.wikipedia.org/wiki/Apple_mobile_application_proce...](https://en.wikipedia.org/wiki/Apple_mobile_application_processors#Apple_T2)

The Apple T2 chip is a SoC from Apple mainly serving as a secure enclave for encrypted keys in the iMac Pro 2017. It gives users the ability to lock down the computer's boot process. It also handles system functions like the camera and audio control, and manages the solid-state drive.

<comment><USER8> So it's basically SecureBoot + lets remove the SATA controller, the audio chip, the H264 chip and roll them into one chip.

It feels like horizontal integration; similar to what Elon Musk does with SpaceX by integrating the pipeline and producing everything internally to save costs.

The article doesn't sound very revolutionary. They're saving money, maybe a little space, by producing all those subsystems themselves. So long as they don't lock down the hardware so you can run Linux or other operating systems on it, I guess that's okay.

Still, it sounds very non-upgradable. The article mentions the memory comes in two banks. Is it replaceable, or is it soldered to the board? nvme ssd cards are super tiny, super fast and super standardized. I can upgrade the ones in most laptops. I can replace a dying battery. Apple seems more geared to people who don't like to fix things or work on their own machines.

<comment><USER9> This is called vertical integration, same for SpaceX.

Horizontal integration is like making computers, and also making elevators (e.g., Samsung)

EDIT: that wasn't a correct example. Horizontal integration would be company making mobile phone SoC, then make server SoC like Qualcomm (since both use the same supply chain).

<comment><USER10> That's called no integration. It's a conglomerate.

</comment></comment></comment></comment><comment><USER11> > For security reasons, the T2 is the iMac Pro hardware's "root of trust," and > it validates the entire boot process when the power comes on. The T2 starts > up, checks things out, loads its bootloader, verifies that it's legitimate > and cryptographically signed by Apple, and then moves on to the next part of > the boot process.

If they start putting this in every machine going forward I wonder if this will be the end of the hackintosh

<comment><USER12> Well, beginning of the end. It would be 3 years from whatever date they release a new version that locks it to a chip like this _and_ drop support for old models without it. So lets say, 4-5 years. Actually, probably longer since they've been supporting old systems for as long as 8 years(2007 imac, others) with some macbook pros approaching 9-10 even.

How long you think it would take for them to do this depends on whether you really think they'd just decide to cut off a ton of machines at once and reverse course on really long support windows. And long windows really seems to be a roadmap, if you look at how the ipad 2 was supported as well.

I think they care more about "look at how we support our products!" than hackintoshes. What i _could_ easily imagine though is way more features than just imessage and such being gate-kept into "only systems with our secure chip are allowed to run this"

<comment><USER13> I understand the security benefits but I can't help but just look at this as yet another piece of disposability on an already very "disposable" piece of 5K+ (starting) hardware.

How many iPhones are now in landfills because you couldn't downgrade the OS to an old version that would be usable.

<comment><USER14> I agree with your main point about disposability. There shouldn't be many iPhones in landfills, though. Apple recycles 100% of the materials, so as long as the old phone can be traded in or dropped off in an electronics bin, it won't be wasted even though the owner will have been out the money by rebuying prematurely.

<comment><USER15> > Apple recycles 100% of the materials

Do you have a source for that? It sounds hard to believe

<comment><USER16> If Apple gets its hands on the phone they have an impressive system for recycling: [http://www.businessinsider.com/apple-liam-iphone- recycling-r...](http://www.businessinsider.com/apple-liam-iphone-recycling- robot-photos-video-2017-4)

I could not find a reliable source for what portion of each phone is recycled, but Apple is certainly not slacking on the recycling front.

<comment><USER15> As far as I can tell, Liam is just an R&D project - it's not something they've put into actual production.

E.g. from the 2017 environmental report

> _For example, we've melted down iPhone 6 aluminum enclosures recovered from > Liam to make Mac mini computers for use in our factories_

It's only recovered enough aluminum to build a couple of Mac minis for their own internal use

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> This is slightly off-topic, but developments such as these really make me look forward to when Apple will finally get around to releasing their new Mac Pro (coyly quasi-announced as not being due for release in 2017, but in development supposedly for a late 2018 or early 2019). This kind of technology might not be revolutionary per se, but makes for a very solid technological basis to build a system on. If the Mac Pro turns out to be an iMac Pro divorced from the screen and with some internal expandability in a suitably fancy-looking case, I'll be very content.

<comment><USER18> I hope that Mac Pro would be good old case with standard components without extra price. I really like macOS but all Apple's computers are just terrible for me. Mac Pro is my last hope to stay in Apple ecosystem.

<comment><USER17> Considering how long it is taking them to develop it, and considering the direction they have taken with their Emoji-keyboard MacBookPros with custom chips and now the architecture of the iMac Pro, the Mac Pro is going to be anything but standard.

<comment><USER19> But they _have_ already developed a non-standard Mac Pro in 2013, and it is widely considered a failure. I'm not sure if they'll really make the same mistake twice?

<comment><USER10> Its not just widely considered a failure, they publicly admitted it was a failure.

[https://techcrunch.com/2017/04/06/transcript-phil- schiller-c...](https://techcrunch.com/2017/04/06/transcript-phil-schiller- craig-federighi-and-john-ternus-on-the-state-of-apples-pro-macs/)

 _Craig Federighi: I think it's fair to say, part of why we're talking today, is that the Mac Pro — the current vintage that we introduced — we wanted to do something bold and different. In retrospect, it didn't well suit some of the people we were trying to reach. It's good for some; it's an amazingly quiet machine, it's a beautiful machine. But it does not address the full range of customers we wanna reach with Mac Pro._

 _But I think we designed ourselves into a bit of a thermal corner, if you will. We designed a system that we thought with the kind of GPUs that at the time we thought we needed, and that we thought we could well serve with a two GPU architecture… that that was the thermal limit we needed, or the thermal capacity we needed. But workloads didn't materialize to fit that as broadly as we hoped._

</comment></comment></comment></comment></comment><comment><USER20> Good to read something positive about CPU technology today :). Beyond the obvious improvements for securing the computer, it is very interesting to see how the T2 chip not only operates the camera but most of all also works as a hard disk controller. So the "CPU" of the computer might be Intel still, but it is a bit of a guest in a system that is in fact controlled by the T2 chip.

As the T2 seems to basically the iPhone CPU it also shows how great a hardware is in current phones now, if using that chip creates a faster flash memory controller for the biggest Intel CPUs.

</comment><comment><USER21> So... I read the article and I still don't know what, exactly, is the T2 chip or what, exactly, makes it different from other ARM / Intel hybrids, other than several different ways of expressing "it's incredibly, totally great" and "Intel is untrustworthy, so let's trust Apple instead" and "this changes everything all over again".

(It doesn't, unless you arbitrarily consider small, incremental changes exclusive to Apple products as the opposite of small and incremental just because of the size of Apple.)

<comment><USER22> It's a chip which replaces the controllers (previously several of them, from different vendors, that Apple didn't have control over) for disk and network I/O, speakers, microphone, camera, cooling system, etc. with a single Apple- designed chip. This lets Apple add features to their hardware unsupported by other controllers, move some features from the CPU to this new chip which can reduce attack surface area and free up CPU cycles for something else, save space on the motherboard, and maybe save money.

</comment></comment><comment><USER23> This just sound like the Intel Management Engine story waiting to happen again. A controller that handles camera, networking and is the "root of trust"? No thank you.

<comment><USER24> > This just sound like the Intel Management Engine story waiting to happen > again

Excuse me, implementation details matter. Outcomes matter. Apple has deployed 10x more devices with no known breach or defect.

<comment><USER25> Are you implying that Apple has deployed 10x more devices than Intel?

<comment><USER26> Yeah, this is all technology from iOS devices.

<comment><USER27> Even so, I somehow doubt that 15 years of iOS devices equals 30+ years of x86 devices.

<comment><USER26> You're right.

I was assuming the parent was thinking about Macs vs. Intel processors. Was just pointing out that the comparison of scale is iOS devices vs. Intel processors.

<comment><USER28> > iOS devices vs. Intel processors

There's no way there are 10x more iOS devices in circulation than Intel-based PCs

Annual PC shipments ( laptops + desktops ) are still above 250 million per year. No tablets haven't killed the market, they've killed growth.

Apple sells about 220 million iPhones per year. I don't know how many iPads; say half as many again?

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> I find it interesting that Apple is back to high levels of customization in its PCs. If I'm remembering correctly, one of the big motivators to move to x86 was to be able to use more commodity stuff through out the system, rather than the all the custom work required to design PowerPC system. I recall initial speculation that Apple's x86 machines would be pretty much fully custom chipsets and designs that just happened to have an x86 CPU, but then when the release systems came out, they used Intel chipsets and were pretty ordinary from a PC hardware standpoint.

<comment><USER30> The biggest motivator to move to Intel, as stated by Steve Jobs in 2005 (paraphrasing from what I remember), was that the power to performance ratio was bad on PowerPC. All the lead that PowerPC had had over Intel vanished.

And given that IBM wasn't interested in servicing Apple's needs for consumer level chips (and Motorola, the other company in the PowerPC consortium, was struggling to scale up manufacturing), Apple's pro machines like the PowerMac were struggling to keep up and improve. One PowerMac model with PowerPC G5 (IIRC) was even released with liquid cooling and had some customers complaining about leaks.

The driver for the processor switch was actually Apple's inability to get the right kind of chips it wanted on scale. As others have mentioned, the in-house design and the ability to get its chips manufactured for iPhones on a large scale triggered a big wave (of competitive advantage) for Apple. We'll only see more of this as time passes.

<comment><USER31> Yeah, I remember Jobs saying they wanted to put a G5 in the Powerbook but couldn't do it because the chip was too power hungry.

</comment></comment></comment><comment><USER32> > For security reasons, the T2 is the iMac Pro hardware's "root of trust," and > it validates the entire boot process when the power comes on. The T2 starts > up, checks things out, loads its bootloader, verifies that it's legitimate > and cryptographically signed by Apple, and then moves on to the next part of > the boot process.

How is this more secure from a locked down system using "standard" UEFI secure boot powered by any other TPM implementation?

I understand that this is not an in-depth technical analysis, mainly catering to the Mac-loving audience of the site and getting them to feel better about their platform of choice.

But I'd be interested to hear why I would trust this Apple T2 chip more than a workstation motherboard with a TPM on it, and secure boot on and loaded only with the keys of myself (in case I were to build my own kernel/bootloader and sign it) or a vendor I trust. I could be missing something, but the process outlined in the article sounds exactly like secure boot.

</comment><comment><USER33> Is this basically an integrated south bridge?

<comment><USER34> Sounds like it to me.

For those that are unfamiliar:

[https://en.wikipedia.org/wiki/Southbridge_(computing)](https://en.wikipedia.org/wiki/Southbridge_\(computing\))

</comment></comment><comment><USER35> > _On most Macs, there are discrete controllers for audio, system management > and disk drives. But the T2 handles all these taks. The T2 is responsible > for controlling the iMac Pro's stereo speakers, internal microphones, and > dual cooling fans, all by itself._

Translation: T2 is a southbridge, but this time with a camera controller, and a TPM in addition to the normal disk, audio codec, peripheral bus, and GPIO functionality.

<comment><USER36> Or T2 is like the Fat Agnus, Denise, and Paula chips all rolled into one, similar to the Amiga. Everything new is just recycled from the past.

<comment><USER37> Came to say the same thing (or see if someone else said it). This looks like classic multiprocessing, and looks like computing, like music and clothing, is also subject to ~20-year fashion cycles for some things.

</comment></comment></comment><comment><USER38> I am wondering on the cost benefits this has with Apple. While it is insignificant with the iMac Pro, it will be important once it is filter down to entry level.

Apple now basically have its own IP in everything. Instead of sourcing and paying IP or chips, they can now mix and match their own and build with TSMC. All with the help of iPhone's R&D. I am pretty sure the next one on the list is WiFi and Bluetooth.

This a potential saving of up to $50 in BOM cost. If you tell most PC vendor a extra $50 profits per machine they would have their eyes wide open.

This roughly translate to a $100 cheaper Retail pricing, but given it is Apple they will likely use this saving to put YET another silly features on the Macbook to sell it at the same price.

</comment><comment><USER39> I'm glad they allow you to completely disable the "secure boot" functionality so that other OSes like Linux can be installed. Glad Apple didn't pull a Microsoft here. I would be delighted, however, if the secure boot functionality was programmable with custom certificates!

</comment><comment><USER40> > This version requires a network connection when you attempt to install any > OS software updates, because it needs to verify with Apple that the updates > are legitimate.

They can't just verify the signatures?

<comment><USER41> By _default_ , they start out at the highest level of security, assuming an always-on network connection. It can be adjusted downward, which those of us reading HN are likely to prefer.

Signature verification alone may confirm that a release is from Apple, but it doesn't confirm that the release hasn't been superseded due to security issues. (Or marketing, if you're conspiracy-minded.)

The "Medium" setting allows older versions of MacOS, so although the article doesn't say, I suspect that is doing signature-verification alone, and does not require a network connection.

<comment><USER40> > Signature verification alone may confirm that a release is from Apple, but > it doesn't confirm that the release hasn't been superseded due to security > issues. (Or marketing, if you're conspiracy-minded.)

But fuse sets will. Thus is how downgrade attacks are generally protected against in high integrity consumer electronics.

That way your device continues to work when you reboot and Comcast is down again.

<comment><USER42> I'm sure the T2 doesn't verify the OS against the network at boot time, but rather when you're installing the OS update. Once it's been installed, it's trusted.

The trivial proof here is if it did anything else, ignoring an OS update would brick your device, which is obviously not desired behavior.

<comment><USER43> > I'm sure the T2 doesn't verify the OS against the network at boot time, but > rather when you're installing the OS update. Once it's been installed, it's > trusted.

This is correct. Network is only needed for re-install on the high security setting. When already installed, the only verification is to ensure signatures are valid, similar to how iOS devices function (You cannot re-flash/downgrade to an older OS, but if you have an older OS installed, the device will not prevent you from booting).

</comment></comment></comment></comment></comment><comment><USER44> I am surprised it has taken this long.

In the Marklar days, this was something we speculated about as a Clone-defeat mechanism. Essentially a hackintosh blocker.

I look forward to following the discoveries made in this subsystem.

</comment><comment><USER45> What is old is new again:

[https://www.folklore.org/StoryView.py?story=Five_Different_M...](https://www.folklore.org/StoryView.py?story=Five_Different_Macs.txt)

</comment><comment><USER46> > Before the iMac Pro was released, there was a lot of speculation that it was > part of a trend toward creating a "hybrid Mac" that is driven by both an > Intel processor and an Apple-designed ARM chip like those found in other > Apple devices. The iMac Pro is definitely a hybrid of a sort, but probably > not the one people were expecting.

Not the thing people were expecting, but still, does anyone know if the T2 is based around one of Apple's ARM cores?

<comment><USER47> The T2 is rumored to be a derivative of the A10.

</comment></comment><comment><USER48> Apple has basically replaced the SMC architecture with a new architecture that is the equivalent of an Apple watch. From an integration perspective, it makes sense. Apple no longer has to source an SMC/arm chip from another supplier, they use their own.

All Mac users have at some point had to reset the SMC on a Mac. The MacWorld comment that the iMac pro because of the T2 chip is unlike another Mac, is only half the story. The Functionality that was handled by the SMC (which was an arm based architecture), is now handled by a more beefier arm chip T2.

It's a cost savings for Apple, and allows for more advanced functionality. In the Interim , the T2 is doing exactly what the SMC used to do.

</comment><comment><USER49> Slightly OT, Apple really needs to release a Macbook Pro or two with beefy video cards -- it's becoming nearly untenable to develop games or for AR/VR with their latest hardware. Their Intel-integrated cards are not up to the task.

<comment><USER50> Isn't this why they added support for externals GPUs?

</comment></comment><comment><USER51> Where is the disk key? Is it stored in the main board, or in the flash disk itself? E.g. if you have to replace the motherboard, do you lose the data, or because of being in the flash disk it is OK? BTW, if being in the flash disk, how secure it is the key handling?

</comment><comment><USER52> When all eyes are now looking to the future of branch prediction, this launch will be a bit obfuscated. Does the Intel Xeon inside the iMac Pro also vulnerable? If so, the impact of the T2 will not get attention as it should.

<comment><USER53> High Sierra fixed the KPTI issue without perfomance loss: [https://twitter.com/aionescu/status/948609809540046849](https://twitter.com/aionescu/status/948609809540046849)

<comment><USER54> "Without performance loss" sounds optimistic, but most things that people would be doing with a Mac likely aren't syscall-intensive enough to show major effects, especially on modernish chips with PCID. Most of the more impressive performance drops from the Linux patch are with things like heavy database workloads.

</comment></comment></comment><comment><USER55> > if you get the 1TB model, your iMac Pro has two 512MB NAND banks

Looks like you meant "GB" here.

</comment><comment><USER56> I love the level of integration with this chip. How big is their IC design team?

<comment><USER30> Not very big, is my understanding. The team mainly came from the PA Semi acquisition several years ago, and there was some recent news about Google hiring ("poaching") a key senior person from this team.

</comment></comment><comment><USER57> It's impossible to read the article because of the ads.

<comment><USER58> It is easily readable with Reader View in Safari.

</comment></comment><comment><USER59> Intel ME? Hold my beer. -- Apple.

</comment><comment><USER60> >The T2 is responsible for controlling the iMac Pro's stereo speakers, internal microphones, and dual cooling fans, all by itself.

So it's just a fancy Super I/O chip

</comment><comment><USER61> "The iMac Pro isn't running iOS apps"

I always find this kind of remarks funny because iOS is essentially a specialised strip down version of MacOS. So basically any accusation of MacOS copying iOS , however exaggerated, is an accusation that MacOS is copying itself.

</comment><comment><USER62> > Every bit of data stored on an iMac Pro's SSD is encrypted on the fly by the > T2, so that if a nefarious person tried to pull out the storage chips and > read them later, they'd be out of luck.

What. The. Fuck. How am I supposed to recover my data e.g. if the mainboard gets fried or the machine has to go to service?! With a SATA or NVMe SSD I can plug them into another computer and either keep going (for Linux and macOS, only Windows is a different beast...) or dump the data to somehere safe. With this, Apple forces me to rely on TimeMachine working - which is not a bad idea in itself, but not cool that this is not widely announced on the product page: "BACK UP THE DATA YOURSELF OR IT WILL GET LOST IF ANYTHING GETS SCREWED UP".

There's already FileVault for encryption (or LUKS, VeraCrypt and Bitlocker), and in addition some SSDs (and iirc also some expensive HDDs) implement native on disk encryption via standardized SATA commands so one has encrypted storage but still portability (and for native disk encryption, no loss due to CPU- level encryption!).

Another reason to not buy anything modern from Apple. If one single problem happens to your modern work machine you're straight out f...ed.

<comment><USER63> What is your plan to access storage if your phone's motherboard gets fried?

<comment><USER64> I, personally love and hate the disappearance of micro-SD cards with phones. Love, because many SD cards are crap, and will lose your data without much notice. Hate, because then there is no recovery option other than "travel back in time to backup your data", if you haven't already backed up your data.

I sort of give phones a pass these days because they are size and weight constrained. Desktop PCs though????? I disagree with the decision not to use a NVMe SSD card slot on this product.

<comment><USER10> Backing up your iPhone to iCloud is turned on by default.

<comment><USER50> So is backing up most of your Mac.</comment></comment></comment></comment></comment>


Show HN: Jently Summarizer - jently-team https://jent.ly <comment> jently-team Hey, Jent.ly team here!

Online articles are often lengthy and descriptive. To save your time and attention, we developed a Chrome extension that summarizes online web pages by highlighting the key points of an article.

Why build another summarization tool? We found that existing tools lacked flexibility and various features. Some required you to copy-paste the source text into their website. Some displayed the summary in a new window or pop-up. Others were website specific, for example only summarizing on Reddit.

We built Jent.ly with that in mind! It works on a variety of websites (news, blogs, reference), highlights the important sentences directly within the page, and doesn't require you to navigate to another website.

Try it out below and let us know how we did!

Download: [https://chrome.google.com/webstore/detail/jently/ljpcoibfhgg...](https://chrome.google.com/webstore/detail/jently/ljpcoibfhggflcmmlbpbcmdkmdnaafeo?hl=en)

Facebook: [https://www.facebook.com/jentlysummarizer](https://www.facebook.com/jentlysummarizer)

Github: [https://github.com/jent-ly](https://github.com/jent-ly)</comment>


OCR "intelligent" software - <AUTHOR> I need help with automatic data extraction from invoice scans and images.
The thing is, I would like to develop automatic system so it knows where is the invoice number, price, date, etc....
The problem is that, each invoice has different layout and I cannot figure out any rule for such system.
Do you have some ideas ? or could you point me into some direction ? Thank you <comment><USER2> An ugly illustration: [https://i.imgur.com/uZWLAaX.png](https://i.imgur.com/uZWLAaX.png)

1\. First you want to detect the location where the invoice number is. There must be something that each invoice share that can help you detect it. If they all have different ways of displaying it, simply see if you can detect any of the possible ways it's displayed.

2\. After detecting where the invoice number is then remove all noise and crop it down to just the invoice number.

3\. Now you got the invoice number only and can use OCR on that to read the numbers.

It's a little more complex than that, but it should help you a tiny bit.</comment>


Solving a DNA Mystery: "The Bizarre Thing About the Bubbling DNA" - <AUTHOR> https://scitechdaily.com/solving-a-dna-mystery-the-bizarre-thing-about-the-bubbling-dna/ <comment><AUTHOR> >Enzymatic degradation of liquid droplets of DNA is modulated near the phase boundary

[https://www.pnas.org/content/117/28/16160](https://www.pnas.org/content/117/28/16160)</comment>


Why free software really isn't (and shouldn't be) free - <AUTHOR> http://www.reddit.com/r/linux/comments/l5jmg/why_free_software_really_isnt_and_shouldnt_be_free/ <comment><USER2> darkduck you've already submitted this blogspam to hacker news at least 3 times previously. Please at least at some new blogspam.</comment>


Verifying Gradle Wrappers with GitHub Actions - <AUTHOR> https://blog.gradle.org/gradle-wrapper-checksum-verification-github-action <comment><AUTHOR> > The gradle-wrapper.jar is a binary blob of executable code that is checked > into nearly 2.8 Million GitHub Repositories.

Which I find terrifying. It's a trap for the unwary.</comment>


20-ton magnet heads to New York - <AUTHOR> http://www.symmetrymagazine.org/article/january-2015/20-ton-magnet-heads-to-new-york <comment><USER2> > _"The technical difficulty in manufacturing such a magnet is staggering," > says Brookhaven Lab physicist David Morrison, co-spokesperson for PHENIX, > one of RHIC's two main experiments. "The technology may be similar to an > MRI—also a superconducting solenoid with a hollow center—but many times > larger and completely customized. These magnets look very simple from the > outside, but the internal structure contains very sophisticated engineering. > You can't just order one of these beasts from a catalogue. "_

Can someone go into more detail about this? What makes it so sophisticated? At the end, it's just a pipe made out of ferrous metals, right? So is it just a very evenly distributed alloy, or what?

Edit: Also, how do you transport something like that along the highway without arriving with three smart cars and a geo metro stuck to the trailer?

<comment><USER3> _Also, how do you transport something like that along the highway without arriving with three smart cars and a geo metro stuck to the trailer?_

It's not charged up, of course.

Moving heavy things that will fit on a standard truck is not difficult. Moving things larger than that is. Some magnet about 20 feet across was moved last year, and they had to close off a roads at night to get the thing to a barge port.

<comment><USER4> > Some magnet about 20 feet across was moved last year, and they had to close > off a roads at night to get the thing to a barge port.

For fun stuff of that sort, there was moving OXCART (the future A12/SR-71) from the Lockheed SkunkWorks assembly plant to Area 51 (a ~750 miles journey with the package being wider than many road at the time) for testing: [http://www.roadrunnersinternationale.com/transporting_the_a-...](http://www.roadrunnersinternationale.com/transporting_the_a-12.html)

And the A380 parts moving through a small french village to reach the assembly plant: [http://www.cnet.com/news/the-giant-airbus-a380-and-the- tiny-...](http://www.cnet.com/news/the-giant-airbus-a380-and-the-tiny-french- village/) Because it's a pan-european project the A380 route is pretty extensive and varied, on the final part of the water journey they actually have to play with the tides as some barge sections need high tide to go through, but bridges require low tide to get under.

</comment></comment></comment><comment><USER5> I love the illustration - [http://www.symmetrymagazine.org/sites/default/files/images/s...](http://www.symmetrymagazine.org/sites/default/files/images/standard/SolenoidMagnet_Scale_Illustration.jpg)

It looks like part of a discarded plan by some deranged megalomaniac.

<comment><USER6> The BaBar project at SLAC was named after the particles it was studying: B (the B meson) and B-bar (its antiparticle). The elephant was an old joke: the mascot of the project was Babar the Elephant, a character from an old French children's book:

[http://en.wikipedia.org/wiki/Babar_the_Elephant](http://en.wikipedia.org/wiki/Babar_the_Elephant)

I imagine that the use of an elephant in this illustration (and in the introduction to the article!) is a reference to the old project mascot. :)

<comment><USER5> I just imagined someone intent on world domination waking up in their secret cave after a heavy night drinking, looking at this and trying desperately to remember what they were planning to do after magnetizing the elephant.

</comment></comment></comment><comment><USER7> Here's a writeup about the move of another superconducting magnet, from Livermore to Seattle: [http://www.phys.ufl.edu/~tanner/PDFS/Thomas12jpack- move.pdf](http://www.phys.ufl.edu/~tanner/PDFS/Thomas12jpack-move.pdf)

</comment><comment><USER8> After all the bashing of the Italian startup visa

[https://news.ycombinator.com/item?id=8890952](https://news.ycombinator.com/item?id=8890952)

After the Rome drug map

[https://news.ycombinator.com/item?id=8909143](https://news.ycombinator.com/item?id=8909143)

Finally something proudly made in Italy!

</comment><comment><USER9> Why don't they list the field strength?

<comment><USER10> 1.5 Tesla, according to [http://en.m.wikipedia.org/wiki/BaBar_experiment](http://en.m.wikipedia.org/wiki/BaBar_experiment) (I don't think this kind of magnet can, in practice, be upgraded, but corrections are welcome)

<comment><USER11> 1.5 Tesla doesn't seem like a lot - MRI's have more.

What makes this one special? The size?

</comment></comment></comment><comment><USER12> It is stuck in St. Louis, they can't get it past the gateway arch.

Just a joke, people, carry on.</comment>


America has more new spaceships on the way - <AUTHOR> https://arstechnica.com/science/2020/06/after-dragons-historic-docking-america-has-more-new-spaceships-on-the-way/ <comment><USER3> Starship has a real potential to be accelerated beyond the schedule given because of the return to the moon.

NASA gave SpaceX a lump of cash a couple of months ago to fully spec out a Moon-lander variant of Starship, along with two other companies. It's outlandishly large compared to its competitors, but SpaceX has this knack for doing things cheaply.

Imagine what happens if NASA looks at all three plans and says "They're all equal in terms of meeting our goals, except that Starship has many times the payload capacity and is cheaper than the others". Add in SpaceX's pretty good record for success, and it could make the decision interesting.

If they are selected, suddenly there would be a lot more money in SpaceX's hands dedicated to developing Starship even faster. They could blow up 2 prototypes per month instead of just 1.

<comment><USER4> I don't see Starship landing on the Moon. It's just too big and unwieldy and will likely topple upon touchdown.

<comment><USER5> Are you an aerospace engineer? Because the credibility of your comment hinges on that.

<comment><USER6> Hey, Kerbal Space Program is a perfectly valid alternative to a degree in Aerospace engineering!

EDIT: Obviously kidding.

<comment><USER7> Resume: -Designed and simulated entire spacecraft and rocket system for hypothetical moon landing. -Simulated thousands of spacecraft lithobraking events to assess spacecraft durability

<comment><USER8> Lithobraking might well become viable with some combination of tethers and electromagnetic accelerators to mediate.

</comment></comment></comment></comment></comment></comment><comment><USER9> It's fun to read articles from a few years ago [1]:

> With SpaceX projecting a first Falcon Heavy flight in 2015, even with some > slippage it seems reasonable to suppose that Falcon Heavy will be at least > as "operational" in 2018–19 as the SLS. Both craft should have made at least > one flight, allowing mission planners to ground future efforts in reality > rather than speculation.

My prediction is that the SLS will never fly. Development might not be cancelled for a long time, because it's a jobs programme, but it will never fly.

If Orion ever goes to the moon, i think it will start the journey on a SpaceX rocket. If Starship works out, then on that. If not, then on Falcon Heavy with extensive in-orbit assembly before the trip. Or perhaps even some four-booster Falcon Super Heavy, although probably not.

[1] [https://thespacereview.com/article/2737/1](https://thespacereview.com/article/2737/1)

<comment><USER10> It'll definitely fly once, but probably not more than that.

The first rocket, scheduled for an unmanned flight in late 2021, is ready-ish. The second flight is currently scheduled for 2023 and I would agree that one will never fly. With both Starship, and to a lesser extent New Glenn flying by then, it would be sheer lunacy to continue with it.

</comment></comment><comment><USER11> Interesting they didn't also include Blue Origin in the mix: [https://www.blueorigin.com/](https://www.blueorigin.com/)

In my opinion, we should see crewed sub-orbital flights from them within the year, and possibly crewed orbital flights in the 4-8 year time frame... where those crewed orbital flights may have capacity to go all the way to the moon.

<comment><USER12> BO has been testing New Shepherd for four years with little visible progress, hoping for crewed flights this year is audacious. It's unclear whether New Shepherd will even be continued based on all the other projects on their plate, and the likely limited demand for their minimal joyrides.

And calling them sub-orbital is being generous. Mercury suborbital flights flew much higher and faster, and actually covered hundreds of miles in a parabolic arc. By comparison New Shepherd is a toy, a very expensive trampoline.

<comment><USER13> > _with little visible progress_

They've been making a lot of progress. The BE-4 engine is under development. And their orbital rocket and lunar lander were announced within the last few years.

It's a slow-and-steady approach, sure, but they're making tangible progress.

<comment><USER12> Press releases aren't progress.

Work on the New Glenn started in 2012. It was publicly announced in 2016. It's still at least a year from flight.

Work on the BE-4 started in 2011. It's first public planned release date was 2017, it's at least 4 years late.

<comment><USER14> Raptor engine development started in 2009. It took ten years for one to actually fly.

<comment><USER12> The Raptor was a tiny project at SpaceX, behind the Merlin, Falcon 9, and Falcon Heavy in investment in its first years, and commercial crew in later years.

BE-4 is the #1 project at BO, which is funding R&D at $1B a year.

</comment></comment></comment></comment></comment></comment><comment><USER4> I wonder how much effort it would take to enable Crew Dragon to fly people to the Moon and pull the rug from under Orion's feet?

A slightly improved heat-shield and some rad-hard electronics would do it IMHO. That would save NASA another $10 billion or so.

I find the statement that there's a public desire for a winged spaceship silly. I haven't heard anyone call out for such a vehicle, certainly no chant from the general public. The dream of an airliner-like space shuttle died when Columbia disintegrated upon reentry.

<comment><USER15> >"I find the statement that there's a public desire for a winged spaceship silly."

I have to disagree. For all the technological achievements of SpaceX, we still don't have the capabilities lost with the Shuttle. No other spacecraft before or since has had the ability to launch 8 astronauts and return multi-ton cargos from LEO. There was also just something so cool about having a freaking _spaceship_ that capsule designs will never have, and that shouldn't be discounted. I couldn't help but feel somewhat depressed watching the Dragon launch like we have regressed as a society, no longer daring to push the limits and strive for absurdley ambitious things like the Shuttle did.

<comment><USER16> Upmass is way more important right now than downmass. If you want more inspiration, know that SpaceX is making a significant profit on these flights despite their price being a small fraction of shuttle flights. And they're pouring it into their next generation rocket, Starship, which they plan to launch around the Moon in a few years.

[https://en.wikipedia.org/wiki/SpaceX_Starship](https://en.wikipedia.org/wiki/SpaceX_Starship)

</comment></comment></comment><comment><USER17> Can someone explain to me why NASA did not use Orion to get crew to the ISS?

<comment><USER18> \- Orion doesn't have the necessary docking adapter.

\- Orion costs well over $1 billion per capsule, plus almost another $2 billion for the SLS rocket to ride on. In total that's more than the $2.6B they paid SpaceX for NRE + 6 flights. (NRE on Orion was $20billion and SLS will be even more)

\- The SLS rocket isn't ready yet.

\- Boeing can't build more than one SLS per year.

<comment><USER19> > Orion doesn't have the necessary docking adapter.

NASA actually enforced a standard docking systems for all capsules: [https://en.wikipedia.org/wiki/NASA_Docking_System](https://en.wikipedia.org/wiki/NASA_Docking_System) . In theory it's androgynous so it might even be possible to dock capsules to each other.

Orion is extremely heavy (26 tons fully fueled) so it would need a Falcon Heavy or D4 Heavy. This would make it very expensive.

It's also politics: since the early 2010s SLS has been the only "supported" vehicle for Orion thus tying the two programs together.

</comment></comment></comment><comment><USER20> I would love if we were going to space united. Humans of Terra got new spaceships on the way.

<comment><USER21> Most countries don't invest much in space. As a percentage of GDP, US is second only to Russia in government civilian space funding. (Given US GDP is over 12 times that of Russia, US spending is higher than Russia in absolute terms.) For your dream to come true, other countries have to increase their expenditure. (My own country Australia is among the guiltiest here - <USER2> Australian Space Agency's budget is less than 10 million a year - it should be a hundred times that.)

</comment></comment><comment><USER22> Love it!</comment>


Hackers for Good: How Anand Prakash Rescued Facebook - <AUTHOR> http://www.csmonitor.com/World/Passcode/Security-culture/2016/1003/Hackers-for-good-How-Anand-Prakash-rescued-Facebook <comment><USER2> Misanthropic observation: 'Good' and 'Rescued Facebook' seems like an oxymoron.</comment>


Unix Wildcards Gone Wild (2014) - <AUTHOR> https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt <comment><USER2> >Simple trick behind this technique is that when using shell wildcards, especially asterisk (...), Unix shell will interpret files beginning with hyphen (-) character as command line arguments to executed command/program.

To be clear, the shell isn't really 'interpreting' anything here — it knows absolutely nothing about the argument conventions of whatever program you're running[0]. All it's doing is passing a list of arguments to an executable; how the executable deals with that is up to it.

And this isn't only a shell problem — it's an issue when you pass arbitrary arguments to ANY external utility in ANY language. For example, maybe you have some kind of tool that calls grep:

        # Perl
        exec '/usr/bin/grep', '-R', $input, 'mydir';

        # PHP (with Symfony Process)
        (new Process(['/usr/bin/grep', '-R', $input, 'mydir']))->run();

        # Python
        subprocess.run(['/usr/bin/grep', '-R', input, 'mydir'])

        # C
        execv("/usr/bin/grep", (char *[]) {"grep", "-R", input, "mydir", NULL});

All of these are safe in the sense that there's no risk of shell command injection (in fact, only the PHP one even calls the shell), but NONE of them are safe against this problem, where the input value might begin with a hyphen. In this grep scenario it's probably not a security issue, but it can produce confusing results for the user if nothing else.

As others mentioned, you must ALWAYS use '\--' to mark the end of option processing when you do something like this.

[0] Technically the shell knows about the conventions of its built-ins, but even those mostly handle arguments in a similar fashion to external utilities, where an arbitrary argv is fed to a function and then parsed using some getopts-like method.

<comment><USER3> You shouldn't assume grep is in /usr/bin. On many systems it's in /bin.

Perl's exec and Python's subprocess already search for executables in PATH, so you don't need to provide the full path.

In C, you can use execvp() instead of execv().

(No idea about PHP…)

<comment><USER2> Right, it was just a random example that popped into my head. You would probably also want to think twice about using -R (at least with GNU grep), about hard-coding the search directory, &c.

All of PHP's process-execution methods (except one, which is unusable on many systems) go through the shell, so by virtue of that it also searches the PATH.

</comment></comment></comment><comment><USER4> I didn't see this mentioned in the article, but you can protect against this in your own scripts by including a -- before user-supplied parameters, which prevents them from being treated as flags.

        $ rm -- -rf
        rm: cannot remove '-rf': No such file or directory

(see Guideline 10, [http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02))

<comment><USER3> Alternatively:

      $ rm ./-rf

<comment><USER5> That if you know such file exist in said folder.

</comment></comment></comment><comment><USER6> This, plus the problem of dealing with files with spaces, newlines, tabs, etc. in their names, are what draw the line for me between "things I am willing to write as a shell script" and "things that will make me use a scripting language† with its own file-manipulation system-call builtins."

A three-line script that takes one file as an argument? Sure, write that in bash.

A script that processes N files passed as arguments? Or that processes a _listing_ of files piped in from stdin? And uses branching logic on the files themselves? Bash goes out the window.

Sure, it's _possible_ to write shell scripts to do that. But why? Unless you're targeting a PDP11 or the Busybox-linked /bin/sh in your initramfs, is shell scripting really the _best_ option?

\---

† Personally, I reach for Ruby in these cases; its stdlib Pathname and FileUtils classes are pretty solid for this use-case, and Ruby interpreters are now roughly everywhere I want to deploy.

Ruby _is_ kind of clumsy for doing all the command piping parts of scripting, though; especially since there's no easy way short of wrapping Kernel.system in your own function to make a Ruby script crash on a nonzero subshell exit status.

I'd love to know if there was a language that was like Ruby in terms of the syntax and semantics around strings, arrays, and files; but then was "just like writing a shell script" in the sense of being able to just use binary names to make "function calls" that are really synchronous subshell spawns and exit-code checks in one (but which still use the variable-passing semantics of the language where the resulting exec(2) ARGV is concerned.) Probably a Ruby DSL is the simplest way to get that—but if it's not in the stdlib, I'm not going to be able to use it for DevOps scripting :/

<comment><USER7> > _A script that processes N files passed as arguments?_

        for filename in "$@"; do
            ...
        done

> _Or that processes a listing of files piped in from stdin?_

That has the tricky bit of "what about filenames that contain newlines" that would come up in an implementation in _any_ language. Since the one byte not allowed in filenames is '\0', let's say that the listing uses '\0' to separate filesnames.

        while read -d '' -r filename; do
            ...
        done

There are things that are hard in Bash... but the things you mentioned aren't them.

> _but which lets you strictly control the ARGV and env of those function > calls without the whole thing passing through a TCL-like stringification and > re-tokenization._

I'm pretty sure that's just Bash, if you remember to wrap everything in double-quotes.

<comment><USER6> That second example is write-only code, and becomes moreso the more things you have to do with the filename. What if you have to reassemble a few of these into an array, filter that array by matching tokens within it, and then feed those arguments through as NUL-separated stdin to another binary, _with_ error checking all along the way to make sure you never call the final command with invalid arguments?

In bash, that's a 50-line monstrosity. In Ruby (or Python, or even Perl), it's ~5 clean, readable lines.

> I'm pretty sure that's just Bash, if you remember to wrap everything in > double-quotes.

Now try composing a command-line in Bash out of those "simply double-quoted values" to pass to ssh as a command to start an ssh exec channel with, where the command also contains a `su -c` stanza.

Again, in another language, that's just a repeated application of a shellescape function as you're composing things. In bash... I have no idea.

\---

These are both examples of the type of code you have to write _all the time_ in Bash when dealing with file manipulation, because any file could have any byte-sequence (except NUL) in its name, and you're dealing with the results of calling commands that want to pipe those filenames out to you as raw delimited data ( _hopefully_ NUL-delimited.)

Let's say you're writing a script that copies a bunch of files into a dir, and then archives them into a tar file. Are you sure your command reads and recreates both relative and absolute symlinks correctly, in a way that they'll unpack correctly for the tar file? In most scripting languages, you've got functions like Pathname#relative_path_from(dir) and Pathname#clean_path. To get the "correct" symlink in bash, you've got `readlink -f` and a comparison and then a bunch of string manipulations using `basename` and `dirname`.

Or how about a "recursively collapse empty or _pseudo-empty_ directory" function? Where, by "pseudo-empty", I mean "empty except for .DS_Store; Thumbs.db; Desktop.ini; those resource-fork files on FAT volumes/SMB shares that start with ._; or other empty or pseudo-empty directories". That's not a function anything ships with, but it's ~10 lines of Ruby. Try to implement it in Bash! (Yes, you can decide whether to collapse the _whole hierarchy_ in one pass with `find`. But the mission here is to remove all the empty _and_ pseudo-empty dirs found in the hierarchy, like an enhanced version of `find -empty`.)

(Notice that these are both examples of things where a Bash programmer would be likely to say "why not write a new binary in C that does this thing, and then call it from your script"? Well, because the whole reason I'm stuck writing in a scripting language is that this code needs to be _portable_ to unknown target CPU ISAs and OS ABIs, silly.)

There is a reason that the default kind of cloud-init script is a YAML file, rather than a Bash script. There is a reason that Vagrantfiles aren't Bash; a reason that Ansible is less popular than Chef or Puppet or Fabric; a reason why every /bin/init that isn't sysvinit has soundly beaten sysvinit. And it's why, even in Ansible, or autotools, or any package manager's pre-install and post-install hooks, the parts where you _do file manipulation_ are abstracted out, either being done through YAML (Ansible), or through domain-specific file-manipulation _binaries_ (dpkg) or through pre-written and thoroughly- checked file-manipulation Bash scripts (autotools).

And that reason is that doing file manipulation directly in Bash is not worth the time and effort, and _especially_ not worth the maintenance burden in a codebase shared with other programmers who are probably not Bash experts.

<comment><USER7> > _That second example is write-only code,_

Tacking on the `-d ''` flag to `read` makes it write-only!?

> In bash, that's a 50-line monstrosity. In Ruby (or Python, or even Perl), > it's ~5 clean, readable lines.

As an example, let's take the input, batch it in to groups of 5, filter-out files that don't contain "token1" or "token2", and pass those as a NUL- separated list to stdin of another binary.

I wrote that up. It came out to 10 lines in either Ruby or Bash. [https://pastebin.com/EksRxmVJ](https://pastebin.com/EksRxmVJ) It's certainly not a "50-line monstrosity"

> _Again, in another language, that 's just a repeated application of a > shellescape function as you're composing things. In bash... I have no idea._

In Bash, "shellescape" is pronounced "printf %q" (and shelljoin is pronounced "printf '%q '"). In Bash, that's similarly just repeated application of printf %q:

        base_cmd=('whatever' 'arg with space')
        nested_cmd=(sh -c "$(printf '%q ' "${base_cmd[@]}")")
        ssh user@hostname "$(printf '%q ' "${nested_cmd[@]}")"

For direct comparison with Ruby:

        escaped=$(printf '%q ' "${base_cmd[@]}")
        escaped=base_cmd.map{|a|shellescape(a)}.join(" ")
        escaped=shelljoin(base_cmd)

Or, Bash 4.4 gained @Q as a shorthand for that:

        base_cmd=('whatever' 'arg with space')
        nested_cmd=(sh -c "${base_cmd[*]@Q}")
        ssh user@hostname "${nested_cmd[*]@Q}"

> _In most scripting languages, you 've got functions like > Pathname#relative_path_from(dir) and Pathname#clean_path._

You mean $(realpath --relative-to=DIR) and $(realpath)?

> _Or how about a "recursively collapse empty or pseudo-empty directory" > function? ... it's ~10 lines of Ruby. Try to implement it in Bash!..._

And it's 6 lines of Bash?

        find \( -not -type d \
                -not -name .DS_Store \
                -not -name Thumbs.db \
                -not -name Desktop.ini \
                -not -name '._*' \
             \) -printf '%h\0%p\0' | sort -uz

Or were you looking for a listing of pseudo-empty directories?

        comm -z23 <(find -type d -print0 | sort -z) \
                  <(find \( -not -type d \
                            -not -name .DS_Store \
                            -not -name Thumbs.db \
                            -not -name Desktop.ini \
                            -not -name '._*' \
                         \) -printf '%h\0%p\0' | sort -uz)

Like I said, there are things that are hard to do in Bash, but I'm not certain you've pointed any of them out.

> _There is a reason that the default kind of cloud-init script is a YAML > file, rather than a Bash script._

And there's also a reason why a "GNU/Linux distro" is essentially a giant pile of shell scripts (maybe embedded in to Makefiles).

> _a reason why every /bin/init that isn't sysvinit has soundly beaten > sysvinit._

I mean, I'm happy with systemd on my systems, but: OpenRC is a giant pile of shell scripts.

> _the parts where you do file manipulation are abstracted out, ... through > domain-specific file-manipulation binaries (dpkg)_

Great example, because the core of Debian is the "rules" file for each package, which is... a Makefile, containing shell.

Or, look at Arch Linux, the core of which is the "PKGBUILD" file for each package, which is... a Bash script.

> _or through pre-written and thoroughly-checked file-manipulation Bash > scripts (autotools)._

Autoconf is targeting shells that _aren 't Bash_. It's pre-written and thoroughly-checked shell that contains wonky workarounds, in order to be compatible with buggy shells from 25 years ago.

If you're assuming "modern shell / utilities", file manipulation in Bash _isn 't hard_.

<comment><USER3> > You mean $(realpath --relative-to=DIR) and $(realpath)?

For historical reasons, some old Debian-based distros (such as Ubuntu 14.04 LTS "Trusty Tahr") doesn't ship with coreutils' realpath. Instead, they have separate, somewhat incompatible realpath package, which doesn't have --relative-to.

Also, beware that $() strips trailing newlines.

<comment><USER7> Good mention! I knew that realpath is a relatively new addition to GNU coreutils, but I didn't realize that older Debians had an incompatible implementation of it.

With a single $(realpath ...), chomping the trailing newline is fine, as realpath will insert a trailing newline after the filename; but definitely something to be aware of with other commands.

<comment><USER3> Newline in realpath (and many other commands) output is mostly for aesthetics. It doesn't help with taming $(), because $() strips _all_ trailing newlines, including the ones that were actually part of the pathname. You would have have to resort to something as ugly as:

       f=$(realpath ... && printf 'x')
       f=${f%x}

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Here are some of my pages on attacks via filenames and how to counter them...

[https://www.dwheeler.com/essays/fixing-unix-linux- filenames....](https://www.dwheeler.com/essays/fixing-unix-linux- filenames.html)

[https://www.dwheeler.com/essays/filenames-in- shell.html](https://www.dwheeler.com/essays/filenames-in-shell.html)

It is not really just a shell problem.

</comment><comment><USER9> This is one of the reasons GNU ls now quotes names with unsafe characters by default, so the common case of copy and pasting output from ls to commands will be safe, or if typing the argument, there is a visual indication of a potential issue.

If one want the older unsafe defaults you can add -N to your ls alias

</comment><comment><USER3> Is there a more comphesensive list of command line options that can be abused in argument injection attacks?

<comment><USER10> One nasty trick is web pages that show a benign code snippet that expands to something evil upon being cut-and-pasted.

<comment><USER11> or my personal favorite are folks who recommend this crap:

        curl https://<whatever> | bash

<comment><USER12> This really isn't as bad and people make it seem. If you're trusting the vendor and aren't going to read the code anyway it's no less safe than installing a package.

I don't _like_ installations like this because they're messy, hard to track, harder to clean up, don't lend themselves to mass deployments, don't provide any integrity verification, the list goes on, but they're not particularly unsafe.

These things exist because there aren't good package that don't require root. Maybe we'll get there eventually.

<comment><USER3> One nasty thing about piping to shell is that the server can detect that this is happening:

[https://news.ycombinator.com/item?id=11532599](https://news.ycombinator.com/item?id=11532599)</comment></comment></comment></comment></comment>


Do hash tables work in constant time? - <AUTHOR> http://www.daniel-lemire.com/blog/archives/2009/08/18/do-hash-tables-work-in-constant-time/

<comment><USER2> This is fantastic, he starts with the claim pure theory is wasteful, experiments must be run to validate models.

He asserts hashtables are not amortized O(1). Ok, interesting, maybe something with caching? latency of disk access in _huge_ data stores? No. He concludes hashtables are not O(1), because integer multiplication is not O(1). No mention of putting an upper bound on the hash key size, like the size addressable memory, or electrons in the universe, just that it's not O(1)

Lucky for us, he's backed it up with a clever and insightful lack of experiments.

 _edit_ spelling and grammar.

<comment><USER3> I'm giving an example (vectorization) where experiments would be needed:

"Am I being pedantic? Does the time required to multiply integers on modern machine depend on the size of the integers? It certainly does if you are using vectorization. And vectorization is used in commercial databases!"

Sorry, I did not run the experiments this time around.

<comment><USER2> You have to admit it's a little silly to start with "This is one of the fundamental reason why pure theory is wasteful." and then not back it up with numbers.

I'm a head in the clouds kind of guy, i'd have been fine if you'd said, here's all this extra stuff you might be overlooking. But when you frame the discussion with concrete measurements... I go looking for concrete measurements.

That said, I broke the rule on not saying something in writing, that i wouldn't say face to face. (well, i would, but only after i knew you better)

I apologize for being snarky. That was uncalled for.

<comment><USER3> Implementing vectorized hash tables is no joke, so I don't think it is silly to have merely evoked the possibility rather than implementing it. It would have taken me days of work, possibly, and even then, people could have questioned my code. I do have a day job, doing academic research and teaching Computer Science. Maybe one day I will research vectorized hash tables, but the result will not be a mere blog post.

<comment><USER2> fwiw, gcc-4.2 foo.c; time ./a.out; gcc-4.2 -ftree-vectorize -ffast-math -ftree-vectorizer-verbose=3 -funsafe-math-optimizations -O3 foo.c; time ./a.out foo.c: In function 'main': foo.c:16: warning: incompatible implicit declaration of built-in function 'printf' 0 real 0m0.095s user 0m0.093s sys 0m0.002s foo.c: In function 'main': foo.c:16: warning: incompatible implicit declaration of built-in function 'printf'

foo.c:6: note: not vectorized: unsupported use in stmt. foo.c:11: note: LOOP VECTORIZED. foo.c:2: note: vectorized 1 loops in function. 0 real 0m0.018s user 0m0.017s sys 0m0.001s

int main () { int a[256], b[256], c[256]; int count = 100000; int i; for(i=0; i < 256; i++) { a[i] = i; b[i] = 255 - i; } do{ for(i=0; i < 256; i++) { c[i] = a[i] * b[i]; } } while(count--); printf("%i", c[0]);// avoid c being optimized away. }

so, i'd assert that vectorized multiplication is a speed win rather than a loss. upping the count a few orders of magnitude indicates vectorized multiplication grows slower than regular multiplication.

So, I claim the vectorization of multiplication is probably not detrimental to the Big O of a hashtable.

ymmv.

</comment></comment></comment></comment></comment><comment><USER4> I don't get it, somebody please correct me if I'm wrong.

Hashtables derive their efficiency from the number of keys that you can encode for a given size hash. If the collision chance is low the number of 'chained' items in each hash bucket approaches one.

To take the length of the key and the number of bits in it as a factor in the complexity of the hash table shifts the problem to a sub-problem that has nothing to do with the original one. As far as the hash table algorithm is concerned that is a different algorithm, whose fixed cost per item is taken into account.

Sure, it is slower to compute a longer hash. But that is not where the majority of the savings are. The majority of the savings are in not having to traverse the N items in the keyspace to find a given key.

Constant factors - and this is one of them - are simply left out because in the greater scheme of things they are but a very small item. Any constant factor, be it 5, 10 or 50 as viewed from the far side of the code calling the hash store is simply that, a constant.

You might be able to optimize on it by using a clever algorithm, you might be able to work it down all the way to '1'.

But that will not change the complexity at all.

</comment><comment><USER5> This seems like a clumsy way to make a simpler and more generic point: _any_ key/value data structure (at least one that relies on inspecting the key in its entirety) will scale as O(NlogN) at very large sizes. The reason is that the size of a key needed to identify a unique entry in a table of size M is at least log2(M) bits long. So the primitive operations on the keys is bounded by log2(M) and is not constant.

This is the same reason that "radix sort" (<http://en.wikipedia.org/wiki/Radix_sort>) isn't a linear operation even though it doesn't seem to have a log(N) dependence on the input set. The number of radix buckets scales as log(N).

That said, of course, this doesn't mean much in practice, where primitive operations on keys live in L1 cache and the pointer indirections require DRAM cycles.

<comment><USER3> My post was specifically about vectorization. In which case, I do claim that it matters.

</comment></comment><comment><USER6> Okay, he is saying that the time required for an arithmetic operation is proportional to the number of bits operated on.

This is true, and it is applicable to other concepts besides hash tables. Can you sort n numbers in O(n log n)? Well a comparison is not really constant- time, in the wall-clock sense of time. If the n numbers are distinct, then each is going to need at least O(log n) bits. So a comparison is O(log n) by the clock, and our sort becomes O(n log n log n).

Part of the solution is to be more precise. For example, when we say that Merge Sort is O(n log n), we usually do not mean that it takes that long to run; we mean that it can require _that many comparisons_. Counting primitive operations can be useful, even if those operations are not constant-time from a wall-clock point of view. And as long as we are clear on what the primitive operations are, everything is fine.

By the way, there is another problem with the statement that hash-table insertion is amortized constant-time: what if all the keys end up being in the same bucket? The true statement is that HT insertion is amortized constant- time _for average data_. (So it's constant-time on average on average. :-)

<comment><USER7> You should not be using n for the number of bits and n for the size of the input.

It may take longer to multiply 128 bit data structures than 64 bit data structures, but it is constant with respect to the size of the hash table.

<comment><USER3> My post specifically refers to vectorization where you may use the fact that you can multiply 4 pairs of 16-bit integers in the time it takes to multiply a pair of 64-bit integers. So, you could operate four 16-bit hash tables in the time it takes to operate a 64-bit hash table.

That's all somewhat theoretical sure, but the point is to challenge your assumptions. (People do use vectorization, right now.)

<comment><USER8> "That's all somewhat theoretical sure, but the point is to challenge your assumptions. (People do use vectorization, right now.)"

You're assuming that people are not aware that multiplication is not always a constant-time operation. That assumption generally doesn't hold among people with any sort of academic CS background. Multiplication algorithms - and the fact that they were typically O(N) in number of bits - were covered in my intro machine architectures course.

In practice, there are many, many other things that can negatively impact hash table performance in a much bigger way. Like cache misses - one cache miss costs far more than an integer multiplication. Or interpreter overhead from using, say, Ruby instead of C (bad example, since Ruby's hashtables are implemented in C, but the general point holds). Or the difference between -O0 and -O3. Or how early versions of Java Hashtables would often devolve into linked lists because the hash function only looked at the first 8 characters of a string.

<comment><USER3> I am not sure optimization, cache misses, and interpreter overhead would obviously impact the computational complexity.

"You're assuming that people are not aware that multiplication is not always a constant-time operation."

I made no such assumption. But I suggest people consider the case of vectorization where, all of a sudden, it may matter quite a bit.

<comment><USER9> You're making a point about where we take cognitive shortcuts. Short version: don't assume the classroom example assumptions always hold in the real world.

</comment></comment></comment></comment></comment></comment><comment><USER10> This is dissapointing. I was really hoping for something more exciting about number of buckets vs number of elements or something like that.

In any event, he was correct when he said: "The problems that result from picking the wrong model of computation are well known and addressed by most textbooks. I have not discovered anything new." There are problems that you can "solve in polynomial time" by encoding the problem as some HUGE number (where the number of bits is exponential in the size of the problem) and doing arithmetic. This is where you really see the breakdown of the constant time arithmetic model.

</comment><comment><USER11> Excerpt from article: _Multiplications of numbers in [0,m) can almost be done in time O(log m). For the purposes of hash tables, the number m must be close to the number of different keys n. Thus—formally—hash tables often run in time O(log n)._

Yes, this guy is confused about Big-O notation — nothing to see here, please move along :)

</comment><comment><USER7> It seems to me he is using the same variable to represent two different quantities:

m- the size of the hash table m- the size of each element in the hash table

The 2nd m should be a different variable, and it is constant with respect to the first m, which is the one we care about.

</comment><comment><USER12> The definition of a hash table is independent of the hash function. You should separately consider the complexity of your hash function.</comment>


An unexpected discovery behind a wall at U-Va. teaches researchers about science - <AUTHOR> https://www.washingtonpost.com/news/grade-point/wp/2015/10/12/an-unexpected-discovery-behind-a-wall-at-u-va-teaches-researchers-about-science/ <comment><USER2> Clickbait title. What was discovered was "[…] _an elaborate chemical hearth designed for laboratory experiments. It was complex, with vents and multiple sources and means of controlling heat._ ".

<comment><USER3> Perhaps. Still a good article and a most intriguing find.</comment></comment>


Metrics Debt - <AUTHOR> http://jamiequint.com/metrics-debt/?utm_source=hacker_news

<comment><USER2> Great post Jamie - not enough business realize the competitive edge they gain from having investing robust metrics setups.

</comment><comment><USER3> Who's using RedShift? How much resources does it take to get on there?

<comment><USER4> Lots of companies, Twitch is one of our clients that uses it and has written about it publicly. Its very easy to set up and you can get started for as little as $200/mo.</comment></comment>


Misunderstanding the Knuth premature optimization quote - <AUTHOR> http://www.bluebytesoftware.com/blog/2010/09/06/ThePrematureOptimizationIsEvilMyth.aspx

<comment><USER2> The actual line from Knuth's article "Structured Programming with go to Statements" is:

(...) "premature emphasis on efficiency is a big mistake which may well be the source of most programming complexity and grief."

Note: not "optimization" but "premature emphasis on efficiency" and "may be the source of complexity and grief" not "root of all evil."

Who invented "root of all evil" then?

Edit: here it is, also Knuth:

" There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance a considered. _We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil._ Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."

OK, there it is, but nicely guarded in a long sentence and not made to be used as some mantra!

Additionally, I agree with Joe Duffy:

"It's an all-too-common occurrence. I'll give code review feedback, asking "Why didn't you take approach B? It seems to be just as clear, and yet obviously has superior performance." Again, this is in a circumstance where I believe the difference matters, given the order of magnitude that matters for the code in question. And I'll get a response, "Premature optimization is the root of all evil." At which point I want to smack this certain someone upside the head (...)"

<comment><USER3> Yea, personally I think it's simply a question of experience. For example lispers prefer the cons+nreverse solution to anything else because it tends to be the fastest way (yes, I've tried to beat it with a "smarter" algo and failed too) while still being clear.

I think the idea of not optimizing for efficiency is a good one, but (like all things) can be taken to extremes. If you consistently choose the slowest way to do something then when you are ready to optimize for performance you'll probably have problems. What do you do if after the bottle necks have been removed, the system is still too slow?

</comment></comment><comment><USER4> Lol. Service Unavailable...Knuth really was wrong. This server should be premature optimized for hacker news :D .

<comment><USER3> If you're having a problem with the performance then by definition fixing it isn't premature.

<comment><USER5> I think he meant that it should have been prematurely optimized so that it could have handled the traffic from hn and there would never have been any problems with performance.

</comment></comment></comment><comment><USER6> Unfortunately, many programmers take the opposite tactic: They shove optimizations in apriori of any testing or data, just because "they know it's faster", or "you should never do X". The result is often convoluted code. The Pareto Principle + Knuth's axiom (as shown by acqq) is the best route through such minefields, IMO.

You may not be one of the "many programmers" but I certainly have worked with enough of them over the years to know just how pervasive they tend to be.

<comment><USER7> it is a typical case of ideology (ie. following principles) approach clashing with the analytical reasoning over real facts/measurements/observations. People everywhere, be it science, programming, politics, religion, ... like to hide in the safe haven of dogmas. Whenever expressing of doubt is prohibited or frown upon - you immediately know what it is a case of ideology/dogma.

</comment></comment><comment><USER8> I've never seen the whole quote; that does make a lot more sense than the fragment we usually see.</comment>


Ask HN: What was this mid-90s phone scam? - <AUTHOR> Back in 1996 -- when I was a reckless, shameless, selfish, stupid and arrogant teenager -- over the course of a summer I got involved in banner ads for porn sites and then spamming for porn sites and finally spamming for a phone sex hotline.
This last one was incredibly profitable, and, I came to believe, a scam which was likely incredibly damaging to its victims, and I regret playing a role. And I've always been curious exactly what was going on with it.
The way it worked was you would sign up with this company online and they would assign you a unique phone number into their hotline. And you'd get paid dollars per minute for calls made to that number, for which they would mail you a check every two weeks.
As far as I could tell, the number had the US country code but was located in the Caribbean and subject to hefty long distance fees. I called the number myself once and sat on hold a while, but was never put through to an operator and never asked for a credit card.
I came to believe that the company never directly collected any money from callers and perhaps did not even have any operators to answer the call, but instead received kickbacks for generating life-destroying phone bills. Has anyone heard of anything like this and can bring clarity to what the situation was? <comment><USER2> The company definitely collected money for the calls. It was the equivalent of a 976 number in the US, that bills by the fraction of a minute. The long distance charges would have gone to the phone company, but I'm fairly certain the company would keep the bulk of the bill. I don't have any insider info, but this was a common scam back in those days. [https://www.newbedfordguide.com/caribbean-phone- scam/2014/01...](https://www.newbedfordguide.com/caribbean-phone- scam/2014/01/10)</comment>


Siggo: A terminal GUI for signal-CLI, written in Go - <AUTHOR> https://github.com/derricw/siggo <comment><USER2> Can someone shed some light on the landscape here? I thought there were only 2 possible ways to use Signal; the mobile apps and the desktop. Is this CLI app somehow talking to them? If anyone can make a client, then what's stopping someone from building better mobile apps and indeed a web client!? Other than of course the sheer effort that's involved obviously.

<comment><USER3> This uses signal-cli[0] (communication happens over D-Bus) and signal-cli in turn uses a patched version of libsignal-service-java[1]. The latter might be used in some of the clients provided by Signal (not sure) but the signal-cli + libsignal-service-java combo talks to Signal servers instead of any apps running locally.

Nothing is stopping you from building a web client for yourself.

[0]: [https://github.com/AsamK/signal-cli](https://github.com/AsamK/signal- cli) [1]: [https://github.com/signalapp/libsignal-service- java](https://github.com/signalapp/libsignal-service-java)

<comment><USER2> I guess libsignal-service-java might be used in the Android app?

<comment><USER3> That's what I was thinking too but then last commit was 7 months ago. Not sure if any of the latest features would have required new code in libsignal- service-java though.

</comment></comment></comment></comment><comment><USER4> You don't need most of the lines drawn in this TUI. You should use slight differences in background color instead.

Lines can be useful for separation, but in this case you should always favor horizontal over vertical lines.

<comment><USER5> I dislike modern "flat" user interfaces which try to remove boxes and lines as much as possible. It makes it harder to get oriented in an app, discern hierarchy, and tell different regions apart. (Maybe reducing boxes saves space, as long as you don't replace them with large regions of whitespace.)

I'm glad that [https://raw.githubusercontent.com/derricw/siggo/master/media...](https://raw.githubusercontent.com/derricw/siggo/master/media/screenshot.jpg) has boxes and line separators, and hope they don't get removed.

</comment></comment><comment><USER6> Too bad Signal API does not bring unencrypted messages. I was also surprised to discover that when you link new devices, you lose history. In general, I ruined a month of text message history, which got into Signal with not way to bring it back (I am referring to the unencrypted text messages).

<comment><USER7> I am pertty sure signal backs up SMS messages and if you enable backups, it looks like you might be able to extract them with this: [https://github.com/xeals/signal- back/blob/master/README.md](https://github.com/xeals/signal- back/blob/master/README.md)

Not great for the non tech-savvy, but I don't know of any SMS backup strategy that is

</comment></comment><comment><USER8> Nice, looking forward to trying this. The Electron-based Mac client uses way too much RAM for what it does.

<comment><USER9> Unfortunately I don't have MacOS building yet [https://github.com/derricw/siggo/issues/6](https://github.com/derricw/siggo/issues/6) but hopefully soon.

</comment></comment><comment> connor-brooks Really nice work, I'll be using this a lot.

Thank you for this!</comment>