Hacker News new | past | comments | ask | show | jobs | submit | aragonite's comments login

I don't know anything about this particular case, but I believe the term "black propaganda" (https://en.m.wikipedia.org/wiki/Black_propaganda) is often used for the kind of situation you have in mind.

I've often wondered about that with some online interactions. Sometimes, a "defense" of P is so poorly argued that it seems almost intentional, as if designed to provoke the well-sourced, well-argued rebuttals that almost invariably follow immediately.

Logically speaking, these rebuttals should not discredit the proposition P itself, only a particular argument for P (e.g. refuting the ontological proof of the existence of God does not thereby refute theism). But when such exchanges happen frequently enough they can give rise to the widespread impression that P has no smart, thoughful defenders, so the overall effect is similar.





My only customization is about tech stack I use & preferences re: generated code. For example if generating for node.js, use import rather than require, prefer fetch() to third party packages, use package A rather than B for sqlite. If generating for C++, make it C-like as much as possible. Etc.

That background leaves out the fact that Skycope itself is literally owned by a (different) Chinese company, so I doubt this is a follow-on of that in any straightforward sense.

> [188] Skycope submits that it and its parent companies have suffered detriment by being forced into extensive litigation in China and that Bluvec and Lizheng’s entry into the market has harmed Skycope and Shengkong’s market position in China. ...

> [222] ... Similarly, there is no evidence that Skycope (including its parent, Shengkong) operates outside of Canada and China.

https://www.canlii.org/en/bc/bcsc/doc/2023/2023bcsc1288/2023...


> ... relaying trade secrets of a Canadian company working in the defence industry to a foreign adversary ...

SkyCope itself is owned by a Chinese company, Shenzhen Shengkong. Bluevec is, if anything, the more "Canadian" of the two companies.

> [188] Skycope submits that it and its parent companies have suffered detriment by being forced into extensive litigation in China and that Bluvec and Lizheng’s entry into the market has harmed Skycope and Shengkong’s market position in China. ...

> [222] ... Similarly, there is no evidence that Skycope (including its parent, Shengkong) operates outside of Canada and China.

https://www.canlii.org/en/bc/bcsc/doc/2023/2023bcsc1288/2023...


This is about selling the trade secrets to "Chinese anti-drone company Beijing Lizheng Technology".

> He stole anti-drone technology from a Canadian company and gave it to China.

No. SkyCope itself is owned by a Chinese company, Shenzhen Shengkong. Also, Bluevec did not "give" the anti-drone tech to "China". It sold it to a (different) Chinese company for $800,000.

> [182] The defendants’ submissions characterize the Bluvec Code as “rudimentary” and say it did not use anything other than technology that was commonly known in the industry. However, Dr. Pan admitted that, while he was still working at Skycope, he wrote direction-finding code for Mr. Jia that later became part of the Bluvec Code. Bluvec subsequently sold that direction-finding technology to Lizheng for $800,000.

> [188] Skycope submits that it and its parent companies have suffered detriment by being forced into extensive litigation in China and that Bluvec and Lizheng’s entry into the market has harmed Skycope and Shengkong’s market position in China. ...

> [222] ... Similarly, there is no evidence that Skycope (including its parent, Shengkong) operates outside of Canada and China.

https://www.canlii.org/en/bc/bcsc/doc/2023/2023bcsc1288/2023...


> SkyCope itself is owned by a Chinese company

Thanks. Edited.

Given Ottawa is using a national security law, it would appear there would be ring-fencing around SkyCope that these companies didn’t have. Curious if SkyCope has military customers in China like at least one of these companies allegedly did [1].

> Bluevec did not "give" the anti-drone tech to "China". It sold it to a (different) Chinese copmany

Don’t court records in China show the company he “sold” it to is controlled by him?

[1] https://web.archive.org/web/20240105144551/https://pegauni.c...


> I'm always looking for alternatives to AutoHotkey and small C WINAPI programs I've written. Rust doesn't quite cut it ...

You can access the win32 api in Node via Koffi. Here's a MessageBox example: https://koffi.dev/start#for-windows

Also see node-activex (https://github.com/durs/node-activex)

AHK2's syntax is also very close to Javascript these days. It's quite pleasant to use and the C++ source is very well-documented.


At the very least Google (or any search engine for that matter) should consider implementing a feature that allows users to explicitly signal query intent. For instance, a 'noshop:' prefix could be used to signal that the user is not looking to buy anything. There are two distinct groups of users searching for terms like "massage ball" or (in my own case) "managed switch": those looking to buy the product and those who looking to learn about the technology. Serving ads to the latter group is not just irritating but also ineffective since those queries were never going to lead to purchases in the first place.

Which Google user would want to pay for ads about things you cant buy ('noshop')?

Oh wait, you meant Google _product_. You want Google to cater to its product needs by sacrificing own money making potential and limiting its actual users.


Google already tries to infer whether a user is shopping or seeking information and serve results accordingly. If I search for "managed vs unmanaged switch" or "massage ball usage", I do not see any ads.

All I'm saying is that Google should consider allowing users to explicitly state their intent, since some queries ("massage ball" and "managed switch") are ambiguous and so the intent cannot always be reliably inferred. Analogy: while type inference works well in many cases, there are situations where explicit typing is required because the type is ambiguous based on usage alone.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: