ntnn

The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting.

Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.

He means the huge window that opens after starting steam and logging in. The window usually has multiple pages with current deals.

I think most people don't see the value in RSS feeds because they are used to the business of forums and social networks - where you don't need (or have the capability to) process _all_ the information.

RSS feeds are perfectly suitable for stuff like blogs, podcasts, webcomics, etc.pp. - not for platforms where a new item pops up every few seconds.

For podcasts people use a separate app like PodcastAddict or iTunes - for webcomics and blogs the author(s) usually also have twitter to announce a new item or an entirely separate platform like DeviantArt or WebToons.

So RSS is indeed not required to keep track of new submissions. I actually have a colleague who isn't using RSS feeds and instead keeps bookmarks and checks each page individually (given he only keeps track of maybe ~30 pages).

In conclusion - I think they don't see a value in RSS feeds because the existing options they're using already fulfill their needs.

Jesus christ, bloomberg does not fuck around.

    Terms of Service Violation
    
    Your usage has been flagged as a violation of our terms of service.
    
    For inquiries related to this message please contact support.
    For sales inquiries, please visit
    http://www.bloomberg.com/professional/request-demo
    If you believe this to be in error, please confirm below that
    you are not a robot by clicking "I'm not a robot" below.
    
    
    Please make sure your browser supports JavaScript and cookies
    and that you are not blocking them from loading. For more
    information you can review the Terms of Service and Cookie
    Policy.
    
    Block reference ID: 2f6bf840-a96b-11e8-8a1f-91588296f859

Then it started to die off with the rise of the web and alternative chat software.

That's news to me and the ~eight IRC networks I'm on.

Slack is perfect for organizations, whereas IRC is not. How so?

And no, we're not locked into anything. How so?

In Germany there is no (general) speed limit

Yes there is. The autobahn may be roughly 50% without speed limits, but every other road has speed limits.

Unless otherwise indicated these are 100 km/h between villages, 50km/h in cities and villages.

Isn't that part of the problem. Lack of sympathy?

For breaking the law?

Does someone have a non region-locked link?

You need someone who can bring other developers along, teach with purpose, and etc. Experience developing alone does NOT automatically provide that.

And the bloke needs time to train. If the developer is getting chased from dumpster to forest fire and back he won't be able to pass on knowledge and best practices.

Use requirements.txt volatile.

We use a separate file to list the direct dependencies, 'ddeps.txt' and 'ddeps-dev.txt' for development deps.

Once we update one of these files a clean venv is created, the dependencies installed and the freeze output saved as requirements.txt. Then the dev dependencies are installed and the output of that freeze is saved to requirements-dev.txt.

This preserves the dependencies where we made the conscious choice to require them and also allows us to explicitly vet any new dependencies and versions.

Sounds just like SUSE Enterprise Support, quality wise. When in doubt "we don't support it" or "we don't support it like that".

... the US armed forces are spending roughly 2b every day (~590b in 2015, proposed ~680b in 2019). That penalty is a drop on a hot stone. That's not a "WIN".

I've tested Ghostery back when it was launched - as with other blockers you could enable/disable blocking per domain and third-party (iirc); you could then use a Ghostery account to synchronize these settings between your devices.

Logging doesn't help you when you business has to shut down because someone took over you account and deleted everything.

Separation of access is important and _required_. Developers don't need access to prod, admins maintaining the infrastructure don't need access to the directory, IDM doesn't need access to either QA or prod.

Developers do need full access in an environment to properly test - but that environment should be basically hermetically sealed from the rest of the companies infrastructure. So even if they do screw up the whole business won't be affected.

Number 2: No One Believes Anyone Can Actually Code

It's about the level and structure of your code. They don't think you _can't_ code, they want to know how _well_ you code.

When I'm interviewing people I let them solve a simple problem as well - it doesn't need to work, it doesn't need to be perfect. I just want to know where the interviewee stands. Case in point - I've had a young-un just out of school in for an interview and his code was clean, commented and had structure.

On the other hand I've had an older bloke in with roughly ten years of experience as a programmer. His code was an absolute mess from start to finish with K&R-style initialization etc.pp.

That is why I want to see how they approach and what code they produce - someone may have been writing code since they were born, but if they never went through a review their code will likely be bad.

Number 3: Coding Tests Can Trip Up Even Good Engineers

That is true, hence a coding test should not be measured on the completion but rather on the approach the interviewee took.

Number 10: You’ll Never Really Know Why You Weren’t Hired

True and bad. I dislike companies who don't give the applicants feedback - or even worse false feedback. Much like in a review - if all you hear is 'no, wrong, bad, ...' you won't improve. You need explanations to single out the issues you can work on (primarily in the short term).

cgroups v2 probably, cgroups v1 is definitely older.

Yes, I've given talks on what containers actually are and which technologies they combine. Containers oldest technology would be mount namespaces from 2002 - the youngest are user namespaces from 2013 (on linux anyway, solaris and IBM had containers before).

People are always amazed that container products are actually mostly just the glue around what the kernel already provides and that their history goes back almost two decades.

But they have, multiple times? First it was just giving people links to godep when people complained in github issues. Then it was a tacit "we like this" about gps and glide. Then it was a pretty-much-official-blessing of dep. Now it's a super-official-now-we-mean-it implementation of vgo. I recognize this as a pattern because I do it all the time, software engineers constantly re-write things from the ground up when they don't care about actually solving the problem and just want to play around with cool new ideas.

No. Golang hasn't had an official/pretty-much-official dependency management system. The community recommends some tools over others, but that's about it.

With dep it is a bit different - the creators were google engineeers and they wanted it to become the official tool, with integration as a go subcommand etc.pp. - but that was never signed off by Pike or any other lead, only confirmed that it would be a possibility if the tools performs well.

With vgo its similar to dep - a proof of concept to see _if_ it works nicely.

Regarding a library multiple tools can use; Yes, that would be a nice thing - however when designing such a tool _and_ a library at the same time you will get into bigger problems. Generally you'll want a library designed by someone who already solved a given problem in at least one way. That brings enough experience to make the correct architectural decisions early on as well as a good, usable API.

I'm happy that we don't just get half-assed solutions just to have one. I have seen enough projects go to shit because a major step in the project was reconsidered a few times before management put a lock on it because it went through 'enough' revisions.

Sorry... what?

The notion that the Python core devs get to decide when Python 2 should stop being used is not cool.

They don't. They just won't support it anymore, nor provide updates for it.

Under the freedoms provided by Free Software licensing, users who have a need to continue to use Python 2 should be able pool their effort to continue to support Python 2.

They can, just not under the name of Python, as this name is owned by the Python Software Foundation. Similarly Canonical would crack down on someone opening a project 'Ubuntu12', continuing to support Ubuntu 12.x versions.

There was an effort called Python 2.8 to do this, but the Python Software Foundation made it change its name and I don't recall what the new name is.

And the people who decided to do this are well within their rights to do so - it is free software after all. Just - as explained in the last paragraph - not with the name Python.

This isn't only to prevent the brand 'Python' to be influenced by a project out of the reach of the foundation, but also to prevent confusion for newcomers.

You should try AquaMail. The search works. Threads aren't shows as a tree, sadly, but they are grouped into a folder - not ideal but you can at least follow simple conversations. Still not something for mailing lists.

Additionally, AquaMail can handle nested folders, which K9 doesn't and never will, according to its developers.

An incognito session would mean he is not using his previous session to gain access. Authentication is more frequently tied to a session than an IP address - this is why you are still logged into HN if you change from your home network to a public wifi, or turn on a VPN.

Yes, that you were aiming at the authentication session hadn't come to my mind as the vulnerability was access without authorization. In the case of a private session or proxy he'd still require a spam mail, create a separate account etc.pp. to just test this explicitly.

He previously provided a link to a telegram chat specifically with 'You can verify what I said in the chat here'. He has since edited the post and is now claiming differently.

That is indeed bad.

He disputed both. > Later, The CEO, Roy Lai, confirms 'only' 21 people of 'over' 1000 were affected. I tried a fileId of over 6k and it works so you do the math, there were definitely more than 2k.

Unless he edited that as well he disputed the total, not the part.

[...]

I concur, what seems to actually have happened is quite worse than the version I read.

Ah, that makes sense - thanks!

Their developers apparently haven't gone through any kind of WebDev or UI/UX 101: https://i.imgur.com/SssYkif.png

The person reporting the bug is not a professional bug hunter, he is a user.

About 1) - an incognito session wouldn't have had any impact on the situation. It's still the same IP the request comes form. Or a proxy? He's a user, not a security expert.

2) He did report it to Sentinel directly over non-open communication channels: https://www.reddit.com/user/notarealhacker/comments/7vpfdl/i... This is also clear from the text, I don't know where you got that from.

3) He didn't dispute that 21 people were affected. He disputed the number of 2000, because he tried numbers over 6000 - and since the id is apparently just an increment (which in itself is already a problem) the number is likely to be false.

From my POV he didn't do anything wrong. He noticed a possible bug, verified it and notified the company. Quite on the contrary - if he _had_ used a proxy and the authorities would've started an investigation to follow all requests it would've looked a lot worse for him.

Mainly relatively unskilled is an understatement. I have a bit of contact with DXC (based in bulgaria, iirc) through a customer. We usually get someone with 'expert X' or 'senior Y' as a job title who lack the most basic skills in debugging and problem solving. It mostly ends in them 'taking a break' (during the call) and in the end we have to do their job.

I don't take an issue with doing their job, but I'm still baffled how DXC can function like that.

If they were to plan this over a longer period of time for all distributions CE is available for I wouldn't have said anything. However they are specifically leaving out the platform most people are using docker on. And not only that - they _are_ providing k8s support with EE on linux. That pretty much deliberately points towards 'buy docker ee if you want this specific feature'.

Tbh, I wouldn't even have said anything if they were making that an EE-only feature. Thing is - they want to make money with that move and they're not honest about it. And in the process they're throwing the larger demograph using docker on the bleeding edge side of things in the mud. The people who are trying the new features on their own servers in their own time.

There has been plenty of hue and cry in the past about the rapid rate of change of Docker

Yes, well - that is what happens when a company decides to use bleeding-edge hipster software. With puppet one minor version may not work with the server whos a few minors behind, with ELK in pre-5 versions the cluster may have gone keel over if the migration of the version hadn't been planned meticularly, with consul you may get better performance (dc-local speaking) than with etcd on one release and way worse the next.

Crying to the devs not to produce good software so quickly shouldn't be the solution.

That sounds like a shoehorned explanation. You're leaving developers on linux out to dry because people aren't paying attention to their production systems?

Don't get me wrong, the work you guys do is cool and all, but that isn't a valid explanation from my point of view. Any company should have some sort of staging to test updated before rolling them out - it isn't up to the developers of the software to take care of this.

And not only that - the switch will come at some point or another either way, so it doesn't make sense to hold that back from CE on linux so that someone doesn't 'find an unexpected and unwanted kubernetes distribution wedged in'. Those who would find that now would also be surprised by that later on.

To add to that - containers are tested using CI/CD tools anyhow, which are predominantly powered by linux machines, which again makes this decision less convincing. The build may be fine on the developers machine and in production, but the CI/CD environment wouldn't reflect both of these environments.

This looks more like a facade for selling more Docker EE licenses rather than wanting to protect users. Which is fine, of course - but then please say that.

Thanks, forbes didn't remove the blurry overlay even after disabling umatrix.

So is everyone only hiring programmers who write code which can be sloppy and full of technical debt and impossible maintain, as long as the product works okay for now?

The result is the only thing the customer and upper management sees. Doesn't matter if it will explode in a few months at best, right then and there it generates revenue and visibility.