HackerTrans
TopNewTrendsCommentsPastAskShowJobs

ZeroSolstice

no profile record

comments

ZeroSolstice
·6 個月前·discuss
I think the saying is "missing the forest for the trees.[1]"

Referring someone to another food bank or resource is not addressing or owning the immediate problem, which is what the experiment showed. Those organizations failed at their primary objective and instead of re-evaluating why they failed they hid behind process and procedure and how they were being tricked since it wasn't a "real" problem.

There was a proper way to handle this situation as anyone who has worked or called into customer service or tech support where their issue was addressed no matter what the internal structure of the organization was.

[1] https://www.merriam-webster.com/dictionary/miss%20the%20fore...
ZeroSolstice
·9 個月前·discuss
[dead]
ZeroSolstice
·9 個月前·discuss
[dead]
ZeroSolstice
·10 個月前·discuss
Correct, which is why .local wouldn't become a TLD or part of a standard for home network reserved domains.
ZeroSolstice
·10 個月前·discuss
I agree it would be great to get some of the vendor pushed / common domains put into an accepted standard.

In my interaction with IETF standards they are created / implemented in two ways:

  1. They set the forward direction for a new technology before it is wide spread.
  2. They wait for a technology to become popular / accepted and start to set standards from that baseline.
Both are reasonable paths of implementation given how the pace of changes in technology.

I doubt .lan, .local, .home, etc will either become public or a standard just based on existing devices that default to these domains and documentation or books that might reference them as example domains.
ZeroSolstice
·10 個月前·discuss
I didn't see a specific RFC that reserved .lan however from the proposed standard RFC 8375 home.arpa is suggested.

https://datatracker.ietf.org/doc/html/rfc8375
ZeroSolstice
·12 個月前·discuss
[dead]
ZeroSolstice
·12 個月前·discuss
[dead]
ZeroSolstice
·12 個月前·discuss
Where? Should they drop them at a starbucks out front? Have an employee volunteer their home address? Put them out front at the office? How long should they hold onto the "free" cables that people are going to ask ridiculous questions such as "Do they work? When were they tested?" Are you going to force people to take all the cable or allow random selections? Are you going to waste the cost savings of moving to the cloud to have one of your tech people monitor requests for pickup? What if no one picks them up are you calling the recycler out again to pick up the cables you could have just given them?

Anyone who has posted "free" things online knows it comes a cost, thats the logic part I was referring too. When you work through the scenarios the "logical" conclusion is to give them to the recycler that you already have out at the datacenter for the systems you are decommissioning.
ZeroSolstice
·12 個月前·discuss
Free pickup? at a secure data center?

Lets use some logic here. The disposal company is taking the cables with them to recycle them for the copper wire. Same with power cables.
ZeroSolstice
·12 個月前·discuss
This is common compliance nomenclature. The only people paying the high cost to have a full sized piece of equipment destroyed are governments or R&D companies with unique prototypes.

The hard drives are most likely being shredded since that is a common practice and certification feature offered by most disposal companies.

The servers are being "destroyed" because thats how they will be accounted for in inventory and tax purposes to account for full depreciation. The company isn't "selling" the servers to the disposal company so they are marked as "destroyed."

Unless specified in the contract the disposal company will sell the chassis without the drives to a reseller or if they are being paid to dispose of the system, they will separate the components and recycle the metal.

The same goes for the power and network cables, they will go off to a recycler, its how disposal companies off-set their pricing.
ZeroSolstice
·去年·discuss
I found that the book "Writing to Learn" by William Zinsser was excellent in convening this process. As noted in the book the author advocated for more writing to be included in all subjects.

  <https://goodreads.com/book/show/585474.Writing_to_Learn>
ZeroSolstice
·去年·discuss
Reading, writing and math have been the constants utilized throughout life and as such have been core subjects carried through educational systems. I'm not quite sure what subjects and topics we would be teaching future generations that didn't include reading, writing, math and science. At the very least writing should be included in more subjects. The hidden feature of including writing in all subjects, as you might have seen in your history endeavor's, is improvements in critical thinking, formulating cohesive arguments and a clearer understanding of topics.

There are greater difficulties that people will have to do in their daily lives than being "forced" to learn how to read, write and do arithmetic. Maybe learning the lesson of overcoming smaller, difficult tasks will allow them to adapt to greater difficulties in the future.

To quote Seneca:

  A gem can not be polished with friction, nor a man perfected without trials.
ZeroSolstice
·2 年前·discuss
This quote mostly applies to people who don't want to spend the time learning existing tooling, making improvements and instead create a slightly different wheel but with different problems. It also applies to people trying to apply "google" solutions to a non-google company.

Kubernetes and all tooling in the cloud native computing foundation(CNCF) were created to have people adopt the cloud and build communities that then created jobs roles that facilitated hiring people to maintain cloud presences that then fund cloud providers.

This is the same playbook that Microsoft did at Universities. They would give the entire suite of tools in the MSDN library away then then in roughly (4) years collect when another seat needs to be purchased for a new hire that has only used Microsoft tools for the last (4) years.
ZeroSolstice
·2 年前·discuss
> The frontpage should directly show the list of papers, like with HN.

I disagree. There are numerous times where I have browsed the comments on a HN post where people haven't read the article and are just responding to the comment thread. The workflow for this seems a bit different in that a person would have already read a paper and wanted to read through existing discussions or respond to discussion. With that, having the search front and center would follow as the next steps for a person who read a paper and wanted to "search" for discussions related to that paper in particular.

HN is more an aimless browsing which is a bit different than researching a specific area or topic.
ZeroSolstice
·2 年前·discuss


  > it hasn't turned around in cyber fwiw and it's been growing for probably 2 decades, 1 decade in earnest. Perhaps b/c SWEs are a profit center vs. the security 
  > cost center, there'll be motivations though. IMO the only thing driving sec eng hiring isn't companies realizing career pipelines are messed up, it's regulations 
  > or getting hacked in profit-damaging ways, and there aren't a ton of companies in those buckets

I don't know from my observations cybersecurity has only been a thing in the last decade outside any defense industry. Before that it was information security and most operations/network security was done by systems and network administrators[1] with the driver being reliability of services verse any concern about the equipment or data on it.

While the hacks are a driver of the cybersecurity field the biggest driver as with all things is insurance companies and cyber coverage. Insurance companies requiring people to be dedicated on keeping up with vulnerabilities, secure default implementations, data restrictions is what is driving the need and companies just want to fill it to keep their coverage or keep their rates lower. Its the typical idea that if you add more software developers or people to a project it gets done faster, when in reality it doesn't work that way. This is why I think we will see a shift back to a more graduated source of cybersecurity professionals. There wasn't a formal path to being a systems administrator or network administrator compared to Computer Science degree -> developer.

Thanks for the astute discussion. Its much better than the "one" line bot responses that you typically see now.

[1] For all the young kids these jobs were renamed DevOPS, NetOPS, SRE, etc. Previously these responsibilities were just part of operating a network.
ZeroSolstice
·2 年前·discuss


  > Because the project was big enough to warrant more than one person.

But based on what, the scope? If you weren't familiar with the tech stack how would you gauge that? I understand people can conceptualize frameworks at a high-level.

  > I have a whole team surrounding me to handle non-technical/non-development incidentals.

Are these the people finding the junior or (5) devs that would be needed. Do they have experience with the framework to know how to scope the project? The hiring of 1 - 5 developers in-house or even as contractors is a labor intensive process so I'm not really sure companies would have just done it based on an idea of an application. I can see where they might have hired early based on winning a contract but they probably under estimated the work if that was the case or padded the cost to account for ramp-up time.

  > Most companies would have had a lot more budgeted and would have pre-hired five devs.

Maybe you haven't worked places that do spikes or just allow people to develop prototypes without entire scoping documents or hiring people. Also keep an eye on your worth here. If you are saving the company the cost involved in getting (5) more developers then you should be getting a bonus or have decent compensation. A lot people fall in this trap of "saving" the company money as if its their own, its not, and unless you are getting some of that savings you are diluting your current pay and working twice as hard.

  > Then everything would have moved glacially slow, fulfilling the prophecy that five devs were needed.

Yeah this is understood as the "mythicial man month" in terms of things slowing down. Adding the wrong head count is a planning and leadership issue. There is nothing stopping teams from being dynamic at a point but that depends on how long the application is going to be supported. Having (5) people now can spread out the working knowledge and workload enough that "no single" developer is holding up forward progress. If you are having to mentor people on the project or fix mistakes then they are the wrong people or wrong skillset for the team. A leader will be able to convey the issue to management and have people let go or replaced. People don't like to do this but there is no reason to keep a failed process going as we are all professionals. Alternatively people above you have accepted this as part of the application development process, it justifies their job, and are fine with it so getting the work done any faster is just a bonus to them.
ZeroSolstice
·2 年前·discuss
I'm not sure I see this as a reality anytime soon.

  > Those folks have a lock bc there’s a small group of who knows assembly and OSs across multiple systems very well and knows if from a security context.

There is two parts to this. The first is for some of these business in that arena I'm sure if they could speed up analysis to take on more client jobs requiring less labor they would have done so. Second is, what output are you going to provide that wouldn't need the very same people to decipher, validate, or explain "what" is going on?

As an example if you get hacked and you make a cyber insurance claim you are going to have to sufficiently explain to the insurance company what happened so they can try to get out of paying you and you won't be able to say "Xyz program says it found malware, just trust what it says." If people don't understand how the result was generated they could be implementing fixes that don't solve the problem because they are depending on the LLM/decision tree to tell them what the problem is. All these models can be gamed just like humans.

I'm not quite sure I agree that a better LLM is what has been keeping people from implementing pipeline logic to produce actionable correlation security alerts. Maybe it does improve but my assumption is much like we still have software developers any automation will just create a new field of support or inquiry that will need people to parse.
ZeroSolstice
·2 年前·discuss
You will start to see this turn around as companies realize they need to go back to the path of entry -> mid -> Senior/Principal. For cybersecurity this is operations and/or development -> cybersecurity w/ focus on either dev or operations. Then at the Senior/Principal layer people can float between things. This isn't too far off from many other jobs, no EE out of school is designing circuits and boards from scratch its debug what Senior EE's have created or problems in existing products, then you work your way up. Its the same with cybersecurity does a person that hasn't developed software start out doing reverse engineering? Does a person develop or approve security policies, devices, network architecture or designs if they haven't every deployed an application or service in production? How are you determining if something is an incident or valid alert if you haven't managed a network.

When money was free companies could hire people for very specific tasks and knowledge areas because it wasn't costing them anything to get the money. This is why lay-offs in engineering, while smaller percentages compared to other departments in the company, are for jobs that are specialized where in previous times it might have made sense to get a consultant or contractor.
ZeroSolstice
·2 年前·discuss
Why did you think you needed to hire a junior dev before even starting work on the application? I know estimation can be a difficult task but the typical "I'm moving so fast..." type experiences usually mean you didn't or don't understand your tooling or the scope.

Also how were you going to take on a junior dev and a new framework at the same time? Were you expecting them to know the framework?

As the saying goes though the last 20% takes 80% of the time.