zcdziura

Just curious: how does one do that? Hash both the binary and source code files, that THAT hash, then sign it? Or am I completely off?

There was an article posted here a while back on how to implement a state machine in Rust, purely using its type system to facilitate state transitions. It's a neat concept, even if it's a bit more verbose than what you'll find in other languages.

https://hoverbear.org/2016/10/12/rust-state-machine-pattern/

I've found that avocado oil is really expensive. I've only been able to find it at my local Whole Foods. Haven't checked Trader Joe's, though I'd wager that if they did have it, it'd be a bit less expensive than WF.

That the company, were it to be a human, would be a 14 year old teenager. 14 year olds, as you know, can be brats due to various reasons (hormones being first among them).

Woooosh...

Seems obvious that someone high up on the corporate ladder, with no practical knowledge in how the nitty-gritty work gets done, made the decision. Probably to "minimize IP theft".

> You're in an industry reaping disproportionate benefit from loose money policies, leading to a trend-chasing culture of overpaid nerds making web apps. You feel guilty about this, but there is nothing you can do about it because you have no other talents that a rational person would pay you for.

/r/2meirl4meirl

But in all seriousness, this was a great article and an exceptionally fun read!

I work for a large brokerage company that has a deeply integrated system written entirely in COBOL on the IBM mainframe. That sucker is going no where, and for good reason: it's incredibly efficient for what it does. As a batch processing system, the mainframe simply can't be beat. We deal with millions of dollars worth of transactions every day that have to be correctly accounted for and reconciled. In order to get the performance required to do all of that, we stick to the mainframe.

However, I do see the appeal for building off of the COBOL foundation using more modern languages. Writing a UI in COBOL on CICS is an absolute nightmare to deal with and maintain (not to mention my firm's egregious install and deployment process that is nothing but red tape and TPS reports). I'm working on a project right now where we're migrating some of our reconciliation screens to the web, where the UI communicates with a Java/Spring Boot server that itself interacts directly to the database using DB2 Stored Procedures.

In this space, I see a need for moving away from COBOL. But for the batch processing? Not a chance.

Pretty sure it's just a joke.

I'm not sure about you, but I have the option of having my EZPass balance refilled automatically after it gets below a certain threshold -- I have mine set at $10, but I don't go through a lot of tolls everyday. I get a statement every month saying when it refills itself from my bank account. Never have to worry about it, even when going on long trips!

I don't think this situation would be worth quitting one's job over. So you didn't get your way after arguing with your peers over it, it happens. As you say, life is short.

Net-new COBOL code is being written every day in the Enterprise world. I work on a team that's actively updating and maintaining a large COBOL codebase. The default standard that most people write to is COBOL-85.

Just because the language is old doesn't mean that it can't be the right tool for the right job. For batch processing-type tasks, there nothing better than COBOL on the mainframe. By default, COBOL doesn't allow for you to dynamically allocate memory. That makes it incredibly easy for the compiler and system to optimize the compiled code and make it run super fast.

COBOL is great for what it was designed for: processing data. If you want to read data from a file/database, process it in some way, and then save that data back to the database/another file, you can't do much better than what COBOL offers.

Many large (or aspiring) open-source projects seek to create a community of users around it, and having a lower barrier of entry to create such a community only helps the project. As you've said, GitHub provides such a low barrier.

Absolutely. In many cases, universities can't afford their own IBM mainframe environment to allow students to learn how to use it. Many folks, such as myself, have to have on-the-job training in order to learn COBOL and how to use the IBM mainframe itself.

In Corporate America, this sort of interaction is completely routine, especially when talking with a single business analyst who's supposed to be representing a whole team. Much of the time, the BA imposes their own requests on-top of their team's. While that's fine, much of the time that is spent on the requirements gets wasted because, after showing off the project to the rest of the business team, they have their own requests that refute what the BA wanted in the first place!

While this would all be solved if requirements were decided as a team, much of the time that's not the case. Alas.

That was a very nice gesture by Google. Made me smile!

Not the OP, but I'm of similar age and also a mainframe programmer by trade. It's a pretty lucrative field to be into, especially because the businesses which operate mainframes tend to be very large and (mostly) stable corporations. While not as hip and cool as a Valley startup, there is something to being well paid and receiving good health and retirement benefits! =)

Those same corporations are also not blind to the fact that most of their COBOL workforce will be retiring, en mass, in the coming years, and are quite desperate to hire anyone willing to learn. My employer paid for me to attend a 3 month training program in order to learn how to use and develop on the IBM zSeries mainframe. It was a fantastic experience. As well, those same companies are looking to move as much of their COBOL code off of the mainframe and onto a distributed, server platform. While you can't beat the sheer power of Big Iron chugging along through a batch cycle, the CICS user interface leaves a lot to be desired. It's much more cost and time effective to build a web interface that talks to a Java middle-layer that lives on the mainframe (such that it can directly talk with DB2 or some such), compared to designing, building, and testing a CICS program to do the same thing, yet in a much more ugly fashion.

There are some libsodium bindings that you can use[1]. Otherwise, there's not a ton of "Made In Rust" crypto libraries, though I know some are being written. I myself am working on a prime number generator library[2], which is fairly usable in its current state.

1. https://crates.io/crates/sodiumoxide 2. https://crates.io/crates/pumpkin

Should you ever write about that experience, I'd be very interested to read it. That sounds awesome!

Careful, you may cut yourself on all that edge.

A very interesting read, thank you for posting! It's cool to see how the Ionic team has worked around the limitations of Github's platform; stepped up and built something useful, rather than complain about it! I like the work ethic.

One side thing that I did want to touch upon was their use of their Ionitron bot to handle "dicey" situations when dealing with other users. Is it really that big of deal telling folks on the internet potentially bad news? So their Pull Request was denied/closed for some reason. Who the hell cares if they throw a temper tantrum? They're nothing more than a username on the Web to the rest of us. As long as the maintainers act with poise and integrity (and I've no reason to think that the Ionic team doesn't do that already) then they'll only be looked at in a favorable light.

What do you mean when stating that applications aren't supported for developing around libcore?

Tape storage is still the most optimal form of long-term storage. If you need to store things for an exceptionally long time, such as financial data, scientific data, etc, then you're going to get the most bang for your buck on tape.

With a Gen1 release, Oculus is trying to build its "core audience" which will be the PC Gamer. Any serious PC gamer will have built their own custom rig to play games. As long as they can nail this audience, they'll be able to grow from there with more "mass consumer" equipment to target lower capability computers.

It's being downvoted not (necessarily) because people think it's offensive, but rather because it's hypocritical.

I'd love to read this article... If it weren't for the paywall.

It's like hell has frozen over!

While the "article" here is fairly light on content, I will say this: Lindsey Sterling (the subject here) is a wonderful artist and absolutely deserves the success she's won. Her music is amazing listen to!

Not very. As disappointed as I am over the lack of inductive charging, like what I currently enjoy with my Nexus 5, the 6P looks like a pretty great device. Huawei's in a great opportunity with that phone to break into the American market.

There's also some practical reasons for keeping a program on the mainframe. I currently work in mainframe development at a large company. We're in the beginning stages of "modernizing" some of our mainframe applications (moving the user interface from CICS to the web). The main workhorse processes will still be on the mainframe, and for good reason: it's a goddamn powerhouse. Should we get a high volumes, we can give the processes some extra CPU's and MIPS, and it'll chug along even faster. It's a bit more difficult to provision extra VMs for a distributed server environment in order to do such things.

Plus, for all of COBOL's faults, it's simply more efficient for "business-y" processes. All anyone cares about is manipulating data found within a file or database, and that's what COBOL excels at.